Linux startup reports interrupted image synchronization #8

Closed
opened 2026-11-04 16:03:10 +01:00 by Alex · 1 comment
Owner

Linux app startup shows Images: Synchronization was interrupted. The last readable cache has been retained. (sync_interrupted) at 2026-11-04 16:00:35. Investigate startup recovery and retry behavior while preserving the readable cache.

Resolution verified

Closing after verification against the current published main branch. The recovery and UI correction is already in commit e48cd75; no additional source change was required for this issue.

sync_interrupted records that a previous inventory scan did not finish. It does not invalidate the last successfully published image cache. Current startup recovery marks the unfinished scan interrupted, removes its incomplete preview pointer, and preserves the published generation. The UI shows a recovery notice with Connect/Resume guidance instead of reporting this historical condition as a current API failure. Explicit Connect/Resume restarts scans; an active connected session schedules retries automatically.

Verification performed

Disposable local data and a synthetic HTTPS provider were used; no real OpenRC credentials, keychain or cloud resources were accessed or mutated.

  • Killed an actual child process with SIGKILL after it committed one complete image generation and a partial second scan. Reopening SQLite retained the complete image, marked the unfinished scan interrupted and cleared its running/preview pointers.
  • Reopened the cache again: recovery was idempotent and the last complete image remained readable. Partial scan rows were never displayed as a complete inventory.
  • Exercised the actual Connections pause/resume RPC path with Coordinator and ResourceInventory. Pause did not restart the scan. Resume cleared sync_interrupted, ran the real SDK image-list calls against local HTTPS, and published the new image generation successfully.
  • Injected a later HTTP 503: the current API failure was reported separately and the published cache was retained. Advancing the retry clock demonstrated automatic retry/backoff recovery without deleting the cache.
  • A successful empty image collection published an empty, complete generation rather than retaining deleted resources.
  • Interrupted an initial scan without any previous successful generation: startup exposed no partial image rows and correctly reported incomplete cache state.
  • Browser checks of CloudProfile confirmed that cached images remain visible while the recovery notice says Connect to restart synchronization; no red API error/unknown_error toast is produced for sync_interrupted. The recovery notice disappears when synchronization recovers. A new service_http_failure still produces the actual Images API notification while cached rows remain visible.

The source implementation and the reported recovery/UI behavior are verified. This does not claim a native production-cloud acceptance run; the broader native/live VM-action acceptance remains tracked separately in #10. All verification scripts/artifacts remain outside the source repository.

Linux app startup shows Images: `Synchronization was interrupted. The last readable cache has been retained. (sync_interrupted)` at 2026-11-04 16:00:35. Investigate startup recovery and retry behavior while preserving the readable cache. ## Resolution verified Closing after verification against the current published main branch. The recovery and UI correction is already in commit [e48cd75](https://git.knoll-systems.de/Alex/openstack-dashboard-app/commit/e48cd753); no additional source change was required for this issue. `sync_interrupted` records that a previous inventory scan did not finish. It does not invalidate the last successfully published image cache. Current startup recovery marks the unfinished scan interrupted, removes its incomplete preview pointer, and preserves the published generation. The UI shows a recovery notice with Connect/Resume guidance instead of reporting this historical condition as a current API failure. Explicit Connect/Resume restarts scans; an active connected session schedules retries automatically. ## Verification performed Disposable local data and a synthetic HTTPS provider were used; no real OpenRC credentials, keychain or cloud resources were accessed or mutated. - Killed an actual child process with SIGKILL after it committed one complete image generation and a partial second scan. Reopening SQLite retained the complete image, marked the unfinished scan interrupted and cleared its running/preview pointers. - Reopened the cache again: recovery was idempotent and the last complete image remained readable. Partial scan rows were never displayed as a complete inventory. - Exercised the actual Connections pause/resume RPC path with Coordinator and ResourceInventory. Pause did not restart the scan. Resume cleared sync_interrupted, ran the real SDK image-list calls against local HTTPS, and published the new image generation successfully. - Injected a later HTTP 503: the current API failure was reported separately and the published cache was retained. Advancing the retry clock demonstrated automatic retry/backoff recovery without deleting the cache. - A successful empty image collection published an empty, complete generation rather than retaining deleted resources. - Interrupted an initial scan without any previous successful generation: startup exposed no partial image rows and correctly reported incomplete cache state. - Browser checks of CloudProfile confirmed that cached images remain visible while the recovery notice says Connect to restart synchronization; no red API error/unknown_error toast is produced for sync_interrupted. The recovery notice disappears when synchronization recovers. A new service_http_failure still produces the actual Images API notification while cached rows remain visible. The source implementation and the reported recovery/UI behavior are verified. This does not claim a native production-cloud acceptance run; the broader native/live VM-action acceptance remains tracked separately in #10. All verification scripts/artifacts remain outside the source repository.
Author
Owner

Implemented the startup recovery presentation in main commit e48cd75 (desktop version 0.8.14).

sync_interrupted is produced when a resource database is reopened with a scan still marked running; it describes the preceding session, not a new Glance HTTP failure. Recovery now atomically clears incomplete preview pointers and retains the last published generation. The UI shows an informational recovery notice with Connect/Resume guidance instead of replaying a historical error toast. Historical interruption does not count as a completed initial sync. Explicit Connect already starts all resource scans.

Validation outside the source repository: simulated process interruption after publishing images, successful reopening and preserved published cache, cleared incomplete preview, successful subsequent scan. Frontend checks pass with zero errors/warnings; production frontend build passes.

The reason the user's original Linux session was interrupted is not established by this message alone. Leaving this issue open for verification after rebuilding 0.8.14: does Images complete after Connect? No full native Linux package or user-cloud test was performed here.

Implemented the startup recovery presentation in main commit e48cd75 (desktop version 0.8.14). `sync_interrupted` is produced when a resource database is reopened with a scan still marked running; it describes the preceding session, not a new Glance HTTP failure. Recovery now atomically clears incomplete preview pointers and retains the last published generation. The UI shows an informational recovery notice with Connect/Resume guidance instead of replaying a historical error toast. Historical interruption does not count as a completed initial sync. Explicit Connect already starts all resource scans. Validation outside the source repository: simulated process interruption after publishing images, successful reopening and preserved published cache, cleared incomplete preview, successful subsequent scan. Frontend checks pass with zero errors/warnings; production frontend build passes. The reason the user's original Linux session was interrupted is not established by this message alone. Leaving this issue open for verification after rebuilding 0.8.14: does Images complete after Connect? No full native Linux package or user-cloud test was performed here.
Alex closed this issue 2026-11-05 19:46:33 +01:00
Sign in to join this conversation.
No labels
No milestone
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Alex/openstack-dashboard-app#8
No description provided.