snowspeeder/pi-web
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: correct the model catalog refresh retry claim

Browse Source 
The five-minute retry recovers from timeouts and unreachable providers,
but not from a provider that answers with an HTTP error status: pi
re-stamps checkedAt on that path, so the unforced retry lands inside a
fresh freshness window. Tracked in #100.
This commit is contained in:
Federico Jaramillo Martinez
2026-07-25 22:12:53 +02:00
parent 92854489cf
commit e7eb5383b2
2 changed files with 6 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/config.html
+5 -4
View File
@@ -675,10 +675,11 @@
</li>
</ul>
<p>
Each run is bounded: it is aborted after <strong>60 seconds</strong>, and a run that times out or fails
earns <strong>one retry after five minutes</strong>. Failures never clear the stored catalogs — the last
successfully fetched models stay in use and the daemon log records what failed. A refresh in flight is
also aborted when the daemon shuts down.
Each run is bounded: it is aborted after <strong>60 seconds</strong>, and a run that times out or cannot
reach a provider earns <strong>one retry after five minutes</strong>; a provider that answers with an
error status is retried on the next scheduled refresh instead. Failures never clear the stored catalogs
— the last successfully fetched models stay in use and the daemon log records what failed. A refresh in
flight is also aborted when the daemon shuts down.
</p>
<p>
Models fetched by a background refresh appear the next time a client asks for the model list, so a model
docs/config.md
+1 -1
View File
@@ -228,7 +228,7 @@ The session daemon runs the refresh:
- **15 seconds after the daemon starts**, then **hourly**. Pi treats stored catalogs as fresh for four hours, so most hourly ticks make no network request at all; the shorter tick only makes sure a due refresh is not delayed to the next tick.
- **Immediately after a provider login or logout**, bypassing that freshness window, because the cached catalog is known to be wrong.
Each run is bounded: it is aborted after **60 seconds**, and a run that times out or fails earns **one retry after five minutes**. Failures never clear the stored catalogs — the last successfully fetched models stay in use and the daemon log records what failed. A refresh in flight is also aborted when the daemon shuts down.
Each run is bounded: it is aborted after **60 seconds**, and a run that times out or cannot reach a provider earns **one retry after five minutes**; a provider that answers with an error status is retried on the next scheduled refresh instead. Failures never clear the stored catalogs — the last successfully fetched models stay in use and the daemon log records what failed. A refresh in flight is also aborted when the daemon shuts down.
Models fetched by a background refresh appear the next time a client asks for the model list, so a model selector left open across a refresh may need to be reopened.