[ECR] [bug]: Pushing to non-existent repo should not EOF
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
What do you want us to build?
When pushing to an ECR repository that doesn't exist, the upload endpoint (ex: `https://123456789012.dkr.ecr.us-east-1.amazonaws.com/v2/mirror/typoed-repository-name/blobs/uploads/`) disconnects with an EOF rather than returning a 4XX status code. Either a 404 or 403 status code would be a lot easier to debug than the remote end hanging up and feeling like there is an ECR outage curiously impacting one only one repository.
**Which service(s) is this request for?**
This could be Fargate, ECS, EKS, ECR
ECR
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
Trying to reduce the amount of time spent debugging failure situations when working with ECR. Additionally, would be helpful if the service behaved in a way to help with ruling out a service outage/bug and assist the user in narrowing down the debugging space with useful and actionable feedback from the API.
**Are you currently working around this issue?**
How are you currently solving this problem?
Spend time debugging. Avoid typos where possible.
**Additional context**
Anything else we should know?
There is at least one other mention of this bug from back in 2021, but was buried in a slightly different thread: https://github.com/aws/containers-roadmap/issues/853#issuecomment-999132800
The specification for the upload endpoint (`end-4a`) says that 404 is only other valid response for the upload endpoint: https://github.com/opencontainers/distribution-spec/blob/acfc11dad63159052f98dd9afab04adf59e6ed8f/spec.md#endpoints It isn't clear that this is the only other valid HTTP status code, but worth highlighting.
**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Contributor guide
Research direction
Start with the ECR upload endpoint URL in the issue and compare its behavior with the referenced OCI Distribution Specification upload-endpoint requirements. Done means pushing to a nonexistent repository returns a useful 404 or 403 response instead of disconnecting with EOF; the payload names no repository files or tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- api, cloud
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100