docs: correct the model catalog refresh retry claim

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.
2026-07-25 22:12:53 +02:00
parent 92854489cf
commit e7eb5383b2
2 changed files with 6 additions and 5 deletions
@@ -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