Repository navigation
Every object download and upload returns 500 when the upstream key contains a dot (e.g. gitlab.com), though startup validation and batch calls accept it #56
Description
Activity
Decision (maintainer, 2026-09-28)
- Map the upstream key to a safe directory name in
ObjectStore. Use an escaped form or a hash, so any key the registry accepts can be stored. Dotted keys likegitlab.comare a natural configuration and must work. - Dotted keys are not rejected at startup.
Next reader: implement the mapping in
ObjectStore(OpenStagingand the lookup paths). It must be deterministic and collision-free, and any existing on-disk layout for currently valid keys must stay readable. Add aProxyFixturetest in which agitlab.comupstream serves both a download and an upload successfully.
Generated by Claude Code
- Map the upstream key to a safe directory name in
Triage
- Category: Bug
- Priority: High. Naming an upstream after its host (
gitlab.com) is the natural configuration, and with it every object download and upload returns 500. Startup and the batch call both succeed, so the misconfiguration surfaces only as per-request failures. - Area / suggested assignment: Storage, in
GitLfsCache/Storage/ObjectStore.cs(IsValidUpstream/OpenStaging), with object-route tests inProxyFixture - Duplicates: none open. It is closely related to When the staging file can't be created, pulls and pushes fail with 500 instead of bypassing the cache #57 (a staging-open failure turns into a 500); both surface at the same
OpenStagingcall sites inObjectRouteHandler. - In progress: no matching open PR. Refuse to publish a staging file whose write failed #59 touches staging publish, not key validation.
Notes: The maintainer decision is to map the key to a safe directory name that is deterministic, collision-free and backward-compatible with existing on-disk layouts, rather than rejecting dotted keys. Keep existing
[A-Za-z0-9_-]keys mapping to themselves, so current caches stay readable without a migration.
Generated by Claude Code
Metadata
Metadata
Assignees
Labels
No labels
What's wrong
ObjectStore.OpenStagingonly accepts upstream keys made of[A-Za-z0-9_-](GitLfsCache/Storage/ObjectStore.cs,IsValidUpstream/IsUpstreamCharacter), and throwsArgumentExceptionotherwise. Nothing earlier applies the same rule:GitLfsCacheOptionsValidator.ValidateUpstreamsdoes not check the key's characters, so startup succeeds.UpstreamRegistryandLfsRouteParseraccept any key, so/…/{upstream}/…/info/lfs/objects/batchworks and the batch is rewritten.The failure only shows up on the object routes:
Endpoints/ObjectRouteHandler.cs:332): the object is fetched from upstream, and thenstore.OpenStaging(route.Upstream)throws. The client gets a 500 and nothing is stored, so every download of every object fails, every time.Endpoints/ObjectRouteHandler.cs:226):OpenStagingis the first thing called, so every PUT fails.Failure scenario
git lfs pullthrough the cache: the batch call returns 200, then every object GET returns 500. A test using the repo's ownProxyFixtureshowed:A dotted key is a natural thing to configure, because upstreams are usually named after their host.
Suggested fix
Either:
GitLfsCacheOptionsValidatorreject keys thatObjectStorewould reject, with a message naming the setting and the allowed characters, so the misconfiguration fails at startup rather than per request; orObjectStore(an escaped form or a hash), so any key the registry accepts can be stored.Acceptance: a configuration with a dotted upstream key is either refused at startup with a clear error, or serves downloads and uploads successfully. There is a test for whichever option is chosen.