docs(agents): an image tag is not a git ref, and /tags echoes your input #38
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs-tag-endpoint"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Documentation only, from verifying a report rather than filing it. It inverts the report.
The beta loop tags the container image and never the repository.
git ls-remote --tagsholdsv0.1.0 v0.1.1 v0.1.2 v0.1.2-beta.20260826052605 v0.2.0 v0.2.1 v0.2.2and nothing else, sov0.2.3-beta.20260827043744exists in the registry and not in git. A contents lookup at that ref reportingobject does not existis correct. A beta build's source is reachable through thesha-<short>image tag or/health'srevision, never through the version its image was published under.And
/repos/{r}/tags/{name}is not an existence check, because its miss echoes your input:A fabricated string produces the identical shape. Any reduction that greps the response for the tag name reports every tag as present, which is how a missing tag looked present and turned an accurate error into a suspected silent failure.
The reported version was that the contents API fails on tags. It does not:
v0.2.2,v0.2.1,v0.2.0andv0.1.0all resolve. The endpoint that lied was the one that looked like corroboration, which is why checking it cost two commands and filing it would have cost somebody an afternoon.Two findings from verifying a report rather than filing it. The beta loop tags the container image and never the repository, so a beta version exists in the registry and not in git ls-remote --tags. A contents lookup at that ref correctly reports that the object does not exist, and a beta build's source is reachable only through the sha-<short> image tag or through /health's revision. And /repos/{r}/tags/{name} returns {"message": "<the name you asked>"} for a name it cannot find, while a real tag returns {"name": ...}. A fabricated string produces the identical shape, so any reduction grepping the response for the tag name reports every tag as present. That is what made a missing tag look like a present one and turned an accurate error from the contents API into a suspected silent failure. The reported version was that the contents API fails on tags. It does not: v0.2.2, v0.2.1, v0.2.0 and v0.1.0 all resolve. The endpoint that lied was the one that looked like corroboration.