aws / aws/containers-roadmap

[ECR] [bug]: Pushing to non-existent repo should not EOF

Open
#1,970 0 comments 8 reactions 0 assignees View on GitHub
ECR Proposed
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.