663c1593df
A multi-GB service update (e.g. nomad_ollama pulling ~6.5 GB) left the Update button clickable with no feedback, so users clicked again thinking it was stuck. The second click raced a concurrent updateContainer run into Docker 304/400 errors (stop/rename on a container the first run had already moved). The backend lock was in-memory only and never written to the DB, so nothing durable signaled "update in progress" to the UI, and a page reload mid-pull re-enabled the button. Backend (docker_service.updateContainer): - Set installation_status='installing' when the update starts and reset it to 'idle' in a finally on every exit path. This mirrors the install path, survives a page reload, and is visible to other tabs/clients. - Reject a second update with a clear message when installation_status is already 'installing', instead of letting it race into Docker errors. Frontend (settings/apps.tsx): - Track in-flight updates per service. Seed optimistically on click and reconcile with the durable installation_status from the server. - Disable the per-service Update button and show "Updating..." while in flight. Drop the fullscreen spinner for updates so the table and the activity feed (live pull/stop/start progress) stay visible. Closes #931 |
||
|---|---|---|
| .. | ||
| zim | ||
| apps.tsx | ||
| benchmark.tsx | ||
| legal.tsx | ||
| maps.tsx | ||
| models.tsx | ||
| support.tsx | ||
| system.tsx | ||
| update.tsx | ||