unkin-agent
7f65fc377c
`sync_interval` is documented only for github_rpm, and the claim gate holding back remotes created inside the current slot also blocks remotes that already have a sync state row: the gate filters the INSERT SELECT, so ON CONFLICT never runs and a failed cold-cache prime waits a full slot instead of its backoff. - document `sync_interval` for github_deb/github_alpine and in the caching field table - apply the created_at gate only when no sync state row exists - test 0→N and N→0 interval changes and the insert-only gate against Postgres - test that a negative `sync_interval` on update returns 400 Reviewed-on: #176 Co-authored-by: unkin-agent <unkin-agent@unkin.net> Co-committed-by: unkin-agent <unkin-agent@unkin.net>
835 B
835 B
github_alpine remote
Shared classification, TTL and eviction rules: caching.
| Type | Mutable (auto-detected) | Immutable (auto-detected) |
|---|---|---|
github_alpine |
APKINDEX.tar.gz (synthesized) |
.apk (redirected) |
Release sync
A background syncer re-scans the GitHub releases list per remote, sharing one
lease per remote across replicas through github_alpine_sync_state.
sync_interval(seconds) re-checks once per interval at a stable per-remote offset, so remotes on the same interval spread out instead of syncing together; its first scheduled sync waits for that slot (a cold-cache request still primes at once). Unset, it re-checks no more often than itsmutable_ttl.- A failed scan keeps serving the last good index and retries with exponential backoff.