You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The proxy cache TTL for a Remote (proxy) repository is configurable over the API (PUT /api/v1/repositories/{key}/cache-ttl) and readable (GET /api/v1/repositories/{key}/cache-ttl), but the web Settings tab does not surface either. Operators currently have to use curl (or read the docs that PR #71 fixed) to inspect or change the TTL — there is no in-UI affordance.
Proposed Solution
Add a "Proxy Cache" section to the existing Settings tab (src/app/(app)/repositories/_components/repo-settings-tab.tsx), shown only when repository.repo_type === "remote":
A read-only "Currently configured TTL" line, populated from GET /:key/cache-ttl. The endpoint already falls back to DEFAULT_CACHE_TTL_SECS (24h) when nothing is stored, so the value displayed is what the proxy will actually apply — matching the contract the doc PR chore: add Vitest coverage reporting #71 spelled out.
An editable input for the new TTL value (in seconds, with a small helper showing the equivalent in minutes/hours/days). Backend validates the range as 1..=2_592_000 (1s to 30d); the UI mirrors that and surfaces a clear inline error for out-of-range values.
The new field plugs into the existing form's hasChanges / "Save Changes" / "Discard" workflow already used for name / description / quota, so operators get one consistent save bar at the bottom rather than yet another submit button.
For non-Remote repos the section is hidden entirely. Backend rejects PUT /:key/cache-ttl on non-Remote with 400 anyway (see is_cache_ttl_configurable); hiding the section avoids letting users build invalid changes that fail at save time.
API wrappers (getCacheTtl, setCacheTtl) go on repositoriesApi in src/lib/api/repositories.ts. The generated SDK already exports getCacheTtl and setCacheTtl, so this is a typed-SDK call — no hand-written apiFetch needed.
Alternatives Considered
Standalone "Cache" tab on the repo detail page. Discoverable but heavyweight for a single integer; the Settings tab already collects all repo-level configuration so a section is a better fit.
Inline editor on the repo header / breadcrumb area. Too noisy; cache TTL is an admin knob, not a primary navigation surface.
Read-only display only, edits via API only. Defeats the point of the issue — we want one-click edits without leaving the UI.
Use Case
As a repository admin operating a remote (proxy) repo, when I notice upstream is publishing fresh artifacts faster than my current 24h default cache lets me serve, I want to inspect the configured TTL and shorten it (e.g. to 1h) directly from the repo's Settings tab — without dropping to curl or reading docs.
Component
Settings
Additional Context
Backend endpoints already exist and the SDK already exposes them — this is a pure UI change.
Companion related work: the per-artifact "Invalidate cache" button shipped via #446 / #447 covers eviction of single entries; this issue is the repo-wide TTL knob.
Pre-submission Checklist
Searched existing issues to make sure this is not a duplicate.
Reviewed the docs / UI to confirm the section does not already exist.
Problem Statement
The proxy cache TTL for a Remote (proxy) repository is configurable over the API (
PUT /api/v1/repositories/{key}/cache-ttl) and readable (GET /api/v1/repositories/{key}/cache-ttl), but the web Settings tab does not surface either. Operators currently have to usecurl(or read the docs that PR #71 fixed) to inspect or change the TTL — there is no in-UI affordance.Proposed Solution
Add a "Proxy Cache" section to the existing Settings tab (
src/app/(app)/repositories/_components/repo-settings-tab.tsx), shown only whenrepository.repo_type === "remote":GET /:key/cache-ttl. The endpoint already falls back toDEFAULT_CACHE_TTL_SECS(24h) when nothing is stored, so the value displayed is what the proxy will actually apply — matching the contract the doc PR chore: add Vitest coverage reporting #71 spelled out.1..=2_592_000(1s to 30d); the UI mirrors that and surfaces a clear inline error for out-of-range values.hasChanges/ "Save Changes" / "Discard" workflow already used for name / description / quota, so operators get one consistent save bar at the bottom rather than yet another submit button.PUT /:key/cache-ttlon non-Remote with 400 anyway (seeis_cache_ttl_configurable); hiding the section avoids letting users build invalid changes that fail at save time.API wrappers (
getCacheTtl,setCacheTtl) go onrepositoriesApiinsrc/lib/api/repositories.ts. The generated SDK already exportsgetCacheTtlandsetCacheTtl, so this is a typed-SDK call — no hand-writtenapiFetchneeded.Alternatives Considered
Use Case
As a repository admin operating a remote (proxy) repo, when I notice upstream is publishing fresh artifacts faster than my current 24h default cache lets me serve, I want to inspect the configured TTL and shorten it (e.g. to 1h) directly from the repo's Settings tab — without dropping to
curlor reading docs.Component
Settings
Additional Context
Pre-submission Checklist