Issues

An upstream Retry-After of 50+ days makes every locks/batch request for that upstream return 500, and shorter long ones freeze it, because the limiter's pause has no ceiling

ktsu-dev/GitLfsCache#126 · opened

on Oct 18, 2026

1

verification_failures metric also counts store-write failures (disk full, I/O error, failed rename), so a full cache volume looks like corrupt upstream content

ktsu-dev/GitLfsCache#125 · opened

on Oct 18, 2026

1

Lock fan-out ignores a Retry-After given as an HTTP-date: the item fails at once and the limiter never pauses

ktsu-dev/GitLfsCache#124 · opened

on Oct 18, 2026

1

Double-encoded dot segments (%252E%252E) bypass the dot-segment guard and the repository allow-list, and climb above a base URL's path prefix

ktsu-dev/GitLfsCache#123 · opened

on Oct 18, 2026

1

Href tokens and lock admission still use BCL HMACSHA256 although ktsu.Essentials has shipped IKeyedHashProvider (HmacSha256) since 2.3.0

ktsu-dev/GitLfsCache#122 · opened

on Oct 17, 2026

1

An upstream action expiring within ~30 s is rewritten to expires_in: 0, which git-lfs reads as "never expires", so the client uses an already-expired proxy token and gets a bare 403

ktsu-dev/GitLfsCache#121 · opened

on Oct 17, 2026

1

Locks: no stale-snapshot grace window after a failed refresh, so a degraded upstream receives every lock-list request

ktsu-dev/GitLfsCache#120 · opened

on Oct 17, 2026

1

Followers wait up to 3× Fetch:FollowerTimeout behind a stalled leader, and re-queue behind leaders that can never publish

ktsu-dev/GitLfsCache#119 · opened

on Oct 17, 2026

1

Upstream HttpClient shares one cookie jar across all clients, so a cookie set for one user is replayed on other users' (and anonymous) upstream calls

ktsu-dev/GitLfsCache#118 · opened

on Oct 17, 2026

1

One cached object larger than the low-water target makes the next eviction sweep empty the whole store, including that object

ktsu-dev/GitLfsCache#98 · opened

on Oct 7, 2026

1

Download whose bytes fail the oid hash check still completes as a clean 200 instead of failing the request

ktsu-dev/GitLfsCache#96 · opened

on Oct 6, 2026

1

The k8s StatefulSet sets no fsGroup, so on block-storage PVCs (EBS, PD, Azure Disk) the non-root pod can't write its store root and crash-loops at startup

ktsu-dev/GitLfsCache#94 · opened

on Oct 6, 2026

1

locks/batch unlock-by-path reads the snapshot without credential admission, leaking which paths are locked and their lock ids

ktsu-dev/GitLfsCache#91 · opened

on Oct 5, 2026

1

Percent-encoded ? or # in the request path truncates the upstream URL, letting a non-trailing ** allow-list pattern be bypassed

ktsu-dev/GitLfsCache#90 · opened

on Oct 5, 2026

1

Allow-list enforcement is only tested on 4 of the route kinds; locks spec tests for replaced-snapshot cursors and the shared fan-out limiter are also missing

ktsu-dev/GitLfsCache#89 · opened

on Oct 5, 2026

1

Batch responses that pick a non-basic transfer adapter still get their hrefs rewritten to the proxy, breaking tus/multipart/custom adapters (design spec: "anything else falls through")

ktsu-dev/GitLfsCache#88 · opened

on Oct 5, 2026

1

The orphan sweep can delete a staging file between CloseAsync and the publish rename: the open-staging guard lifts at close, not after the move

ktsu-dev/GitLfsCache#87 · opened

on Oct 5, 2026

1

An unreachable upstream (DNS failure, connection refused, TLS error, reset) returns a bare 500 on batch, transfer, verify and relay routes instead of 502/504

ktsu-dev/GitLfsCache#86 · opened

on Oct 5, 2026

1

No container image has been published since 2026-08-26: the CI migration dropped the ghcr publish job, but README and deploy/k8s still pull ghcr.io/ktsu-dev/gitlfscache:latest

ktsu-dev/GitLfsCache#80 · opened

on Sep 29, 2026

1

`locks/batch` failure results drop upstream's `lock` object, so a 409 conflict no longer says who holds the file, and exhausted retries always report 429

ktsu-dev/GitLfsCache#78 · opened

on Sep 29, 2026

1

No bytes-evicted metric: eviction sweeps are only visible in logs (spec instrumentation item missing)

ktsu-dev/GitLfsCache#75 · opened

on Sep 28, 2026

1

One network error on a single locks/batch item turns the whole fan-out into a 500, discarding locks upstream already granted

ktsu-dev/GitLfsCache#74 · opened

on Sep 28, 2026

1

No lock snapshot-size metric: operators can't see how close a repository is to MaxSnapshotLocks (spec instrumentation item missing)

ktsu-dev/GitLfsCache#72 · opened

on Sep 28, 2026

1

Unlock by path fails with 404/409 when the snapshot names a released-and-reissued lock id: the spec's one refresh + one retry isn't implemented

ktsu-dev/GitLfsCache#71 · opened

on Sep 28, 2026

1

A lock created or released during an in-flight lock-list refresh is missing from listings for a full ListTtl: the refresh publishes its stale walk after the invalidation ran

ktsu-dev/GitLfsCache#70 · opened

on Sep 28, 2026

1

Navigation Menu

Repository navigation

Issues

An upstream Retry-After of 50+ days makes every locks/batch request for that upstream return 500, and shorter long ones freeze it, because the limiter's pause has no ceiling

verification_failures metric also counts store-write failures (disk full, I/O error, failed rename), so a full cache volume looks like corrupt upstream content

Lock fan-out ignores a Retry-After given as an HTTP-date: the item fails at once and the limiter never pauses

Double-encoded dot segments (%252E%252E) bypass the dot-segment guard and the repository allow-list, and climb above a base URL's path prefix

Href tokens and lock admission still use BCL HMACSHA256 although ktsu.Essentials has shipped IKeyedHashProvider (HmacSha256) since 2.3.0

An upstream action expiring within ~30 s is rewritten to expires_in: 0, which git-lfs reads as "never expires", so the client uses an already-expired proxy token and gets a bare 403

Locks: no stale-snapshot grace window after a failed refresh, so a degraded upstream receives every lock-list request

Followers wait up to 3× Fetch:FollowerTimeout behind a stalled leader, and re-queue behind leaders that can never publish

Upstream HttpClient shares one cookie jar across all clients, so a cookie set for one user is replayed on other users' (and anonymous) upstream calls

One cached object larger than the low-water target makes the next eviction sweep empty the whole store, including that object

Download whose bytes fail the oid hash check still completes as a clean 200 instead of failing the request

The k8s StatefulSet sets no fsGroup, so on block-storage PVCs (EBS, PD, Azure Disk) the non-root pod can't write its store root and crash-loops at startup

locks/batch unlock-by-path reads the snapshot without credential admission, leaking which paths are locked and their lock ids

Percent-encoded ? or # in the request path truncates the upstream URL, letting a non-trailing ** allow-list pattern be bypassed

Allow-list enforcement is only tested on 4 of the route kinds; locks spec tests for replaced-snapshot cursors and the shared fan-out limiter are also missing

Batch responses that pick a non-basic transfer adapter still get their hrefs rewritten to the proxy, breaking tus/multipart/custom adapters (design spec: "anything else falls through")

The orphan sweep can delete a staging file between CloseAsync and the publish rename: the open-staging guard lifts at close, not after the move

An unreachable upstream (DNS failure, connection refused, TLS error, reset) returns a bare 500 on batch, transfer, verify and relay routes instead of 502/504

No container image has been published since 2026-08-26: the CI migration dropped the ghcr publish job, but README and deploy/k8s still pull ghcr.io/ktsu-dev/gitlfscache:latest

`locks/batch` failure results drop upstream's `lock` object, so a 409 conflict no longer says who holds the file, and exhausted retries always report 429

No bytes-evicted metric: eviction sweeps are only visible in logs (spec instrumentation item missing)

One network error on a single locks/batch item turns the whole fan-out into a 500, discarding locks upstream already granted

No lock snapshot-size metric: operators can't see how close a repository is to MaxSnapshotLocks (spec instrumentation item missing)

Unlock by path fails with 404/409 when the snapshot names a released-and-reissued lock id: the spec's one refresh + one retry isn't implemented

A lock created or released during an in-flight lock-list refresh is missing from listings for a full ListTtl: the refresh publishes its stale walk after the invalidation ran