Replies: 1 comment
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Select Topic Area
Bug
Body
500 Internal Server Error when pushing images concurrently to GHCR
Summary
GitHub Container Registry (GHCR) intermittently returns 500 Internal Server Error responses when pushing container images concurrently. The error appears only when multiple
docker pushcommands are executed in parallel from the same client. Switching to sequential/synchronous pushes eliminates the errors entirely.Problem Description
When pushing multiple Docker images or tags to GHCR in parallel (via threading/multiprocessing), some push operations fail with:
The Docker CLI returns exit code 1, with empty stdout and the above error in stderr.
Key observation: Changing from concurrent to sequential pushes completely resolves the issue, suggesting GHCR has difficulty handling simultaneous push requests from the same client/authentication context.
Environment
python-on-whaleswrapper)docker image pushcommandsObserved Behavior
Concurrent Push (Fails)
Result: Intermittent 500 errors on one or more push operations
Sequential Push (Works)
Loop over images and call
docker pushone at a time.Result: No errors, all pushes succeed
Full Error Traceback
Reproduction Steps
docker pushcommands concurrently using threading/multiprocessing (ThreadPool with 4 workers)To verify it's a concurrency issue:
5. Change the same code to push images sequentially (one at a time in a loop)
6. Observe that all pushes now succeed without errors
Questions
3.If concurrent pushes are rate-limited or constrained, would it be possible to return a more specific HTTP status (for example, 429 Too Many Requests with retry guidance) instead of a generic 500 Internal Server Error? That would help us implement proper backoff strategies on our side.
Additional Debug Information Available
We can provide upon request:
docker --debugoutput for failed pushesCurrent Workaround
Push images sequentially instead of concurrently. This is slower but reliable until the server-side issue is resolved.
Beta Was this translation helpful? Give feedback.
All reactions