diff --git a/.changeset/session-start-progress-visibility.md b/.changeset/session-start-progress-visibility.md new file mode 100644 index 0000000..1f4afcc --- /dev/null +++ b/.changeset/session-start-progress-visibility.md @@ -0,0 +1,5 @@ +--- +"@jmfederico/pi-web": patch +--- + +Say what a slow session start is waiting on. While a session is being created or opened, the activity line now names the current startup step — starting the Pi session, or loading session extensions — and adds a note when provider model lists happen to be refreshing at the same time. When nothing can be attributed, the previous generic wording is kept rather than guessing a cause. diff --git a/docs/config.html b/docs/config.html index de15458..cb53e8a 100644 --- a/docs/config.html +++ b/docs/config.html @@ -699,9 +699,16 @@

Background model catalog refresh

PI WEB shares one model runtime across all sessions, and provider model catalogs are refreshed over the - network only on the session daemon's own background schedule. Nothing a browser or API request triggers - waits on a provider catalog fetch, so a slow or unreachable provider cannot stall opening the model - selector, starting a session, or the auth dialogs. + network only on the session daemon's own background schedule. Requests never start a catalog fetch of + their own, so a slow or unreachable provider cannot stall opening the model selector, starting a session, + or the auth dialogs on its own account. +

+

+ A refresh that is already in flight can still briefly delay starting or opening a session, + because the shared runtime is read while that refresh is running. PI WEB says so while you wait: the + session's activity line names the startup step it is on and adds + provider model lists are refreshing when a background refresh is running at the same time. + That note reports what is happening concurrently, not a proven cause.

The session daemon runs the refresh: