Network subnet summary fails with unknown_error and sits above the main panel #14

New issue

Closed

opened 2026-11-05 18:05:18 +01:00 by Alex · 0 comments

Alex commented

2026-11-05 18:05:18 +01:00

Owner

Delivery status

All five commits (044888a, 53e680d, 3630678, afb0eb2, 6df1532) are now pushed to origin/main. Remote HEAD was verified as 6df1532cca8632c0c2c6066faf1b9ec2ab5de076.

The scoped implementation and local source/browser/worker verification described below are complete and delivered. Closing this implementation/fix issue. Remaining native desktop and live-cloud acceptance is tracked centrally in #10; no native/live-cloud pass is claimed. Older paragraphs describing an unpushed change or per-issue confirmation hold are superseded by this delivery status.

User reports that inside an opened network the subnet summary shows "Cloud request failed. (unknown_error)" instead of data and is aligned above the main network panel. Investigate the real connected-session RPC path and error mapping, and align the summary with the main panel below the shared network toolbar/tabs. Earlier mocked browser checks did not exercise the actual connected worker session. Create regression evidence outside the source repository and validate relevant source contracts/builds.

Corrections implemented locally

Commit 3630678 (pushed to origin/main):

Extracted shared network navigation into NetworkHeader above both columns. The main overview/table and subnet summary now share the same top edge, including the Ports tab; narrow layouts stack.
Reproduced a data-visibility defect: the summary read only published subnets, hiding first-scan pages already visible in the inventory. It now reads published data preferentially, otherwise the current/retained initial preview. Port counts remain unknown until both required generations are complete.
Retain the last loaded page when refresh fails instead of clearing it immediately.
Added fixed messages for connection_failed/invalid_request/invalid_query and summary failures. A rejected summary intent identifies unsupported/mismatched app components; malformed response shapes become malformed_cache_response rather than a JavaScript exception rendered as unknown_error. Exception messages/secrets are not exposed.

Evidence and remaining uncertainty

Svelte check (zero errors/warnings), Vite build, source manifests, SQLite summary tests including partial/failed first scans, and a real connected Coordinator + ResourceInventory + Connections route against a disposable HTTPS provider passed. Full CloudProfile browser checks confirmed equal panel top positions below shared navigation in overview and Ports, responsive layout, retained counts on failed refresh, and fixed actionable worker/protocol errors.

The existing bundled profile-worker was inspected and contains network_summary and its request handler. The reporter's exact underlying runtime failure has NOT been reproduced or identified; the successful connected-route test does not prove their cloud/session works. Asked how the affected app was started (rebuilt desktop app, development start, or previously installed app); answer remains pending. No real cloud mutations were performed.

Issue remains OPEN for the original runtime error and native/reporter verification. The alignment and partial-cache visibility defects have source fixes; do not interpret this as confirmation that all live summary failures are resolved.

Matching load failure reproduced and corrected

Follow-up local commit afb0eb2 (pushed to origin/main) reproduces and fixes a concrete route to the originally reported error:

Hold a SQLite write transaction on the resource database, as the separate operation journal lane can do.
The old status reader executes INSERT OR IGNORE even for existing collections, and the old summary reserves BEGIN IMMEDIATE for a read. They fail with sqlite3.OperationalError / SQLITE_BUSY after about 152 ms.
Run the application code extracted from the existing worker archive through its actual stdin/stdout process protocol under that lock: the response is exactly {"ok":false,"code":"connection_failed"}. The original frontend lacked a message for this code and displayed unknown_error.
With the corrected source worker process and the same held writer transaction, the response succeeds and returns the subnet with portCount=1. The direct summary read completed in less than 1 ms in this local case.

Correction: existing collection entries are read before any insertion; status reads do not create absent entries; overview aggregation uses a consistent deferred WAL read snapshot with non-creating entry lookup. Write/publication transactions still use BEGIN IMMEDIATE by default. No credential, API permission or cloud mutation behavior changed.

Verification passed: real worker process round trip with serialized profile/cache bindings; archived-code before/after failure comparison; writer contention including missing collections with SQL trace confirming no INSERT/UPDATE/DELETE/BEGIN IMMEDIATE; subsequent successful cache publications; summary paging/isolation/partial/legacy cases; cache recovery; real connected Coordinator/ResourceInventory route; operation journaling and 34 actual-SDK cases; Python/source manifests.

Build limitation: the existing packaged executable itself cannot start on this harness because its bundled math extension requires GLIBC_2.44. Archived application code was therefore executed with the compatible host Python runtime; this is not a successful native packaged-runtime test. The GLIBC mismatch is not claimed as the cause of the reporter's subnet error.

The matching contention failure is now confirmed and fixed in source. The issue remains open pending a rebuilt desktop app and reporter/native runtime confirmation.

## Delivery status All five commits (`044888a`, `53e680d`, `3630678`, `afb0eb2`, `6df1532`) are now pushed to `origin/main`. Remote HEAD was verified as `6df1532cca8632c0c2c6066faf1b9ec2ab5de076`. The scoped implementation and local source/browser/worker verification described below are complete and delivered. Closing this implementation/fix issue. Remaining native desktop and live-cloud acceptance is tracked centrally in [#10](https://git.knoll-systems.de/Alex/openstack-dashboard-app/issues/10); no native/live-cloud pass is claimed. Older paragraphs describing an unpushed change or per-issue confirmation hold are superseded by this delivery status. User reports that inside an opened network the subnet summary shows "Cloud request failed. (unknown_error)" instead of data and is aligned above the main network panel. Investigate the real connected-session RPC path and error mapping, and align the summary with the main panel below the shared network toolbar/tabs. Earlier mocked browser checks did not exercise the actual connected worker session. Create regression evidence outside the source repository and validate relevant source contracts/builds. ## Corrections implemented locally Commit `3630678` (pushed to origin/main): - Extracted shared network navigation into NetworkHeader above both columns. The main overview/table and subnet summary now share the same top edge, including the Ports tab; narrow layouts stack. - Reproduced a data-visibility defect: the summary read only published subnets, hiding first-scan pages already visible in the inventory. It now reads published data preferentially, otherwise the current/retained initial preview. Port counts remain unknown until both required generations are complete. - Retain the last loaded page when refresh fails instead of clearing it immediately. - Added fixed messages for connection_failed/invalid_request/invalid_query and summary failures. A rejected summary intent identifies unsupported/mismatched app components; malformed response shapes become malformed_cache_response rather than a JavaScript exception rendered as unknown_error. Exception messages/secrets are not exposed. ## Evidence and remaining uncertainty Svelte check (zero errors/warnings), Vite build, source manifests, SQLite summary tests including partial/failed first scans, and a real connected Coordinator + ResourceInventory + Connections route against a disposable HTTPS provider passed. Full CloudProfile browser checks confirmed equal panel top positions below shared navigation in overview and Ports, responsive layout, retained counts on failed refresh, and fixed actionable worker/protocol errors. The existing bundled profile-worker was inspected and contains network_summary and its request handler. The reporter's exact underlying runtime failure has NOT been reproduced or identified; the successful connected-route test does not prove their cloud/session works. Asked how the affected app was started (rebuilt desktop app, development start, or previously installed app); answer remains pending. No real cloud mutations were performed. Issue remains OPEN for the original runtime error and native/reporter verification. The alignment and partial-cache visibility defects have source fixes; do not interpret this as confirmation that all live summary failures are resolved. ## Matching load failure reproduced and corrected Follow-up local commit `afb0eb2` (pushed to origin/main) reproduces and fixes a concrete route to the originally reported error: 1. Hold a SQLite write transaction on the resource database, as the separate operation journal lane can do. 2. The old status reader executes `INSERT OR IGNORE` even for existing collections, and the old summary reserves `BEGIN IMMEDIATE` for a read. They fail with `sqlite3.OperationalError` / `SQLITE_BUSY` after about 152 ms. 3. Run the application code extracted from the existing worker archive through its actual stdin/stdout process protocol under that lock: the response is exactly `{"ok":false,"code":"connection_failed"}`. The original frontend lacked a message for this code and displayed unknown_error. 4. With the corrected source worker process and the same held writer transaction, the response succeeds and returns the subnet with portCount=1. The direct summary read completed in less than 1 ms in this local case. Correction: existing collection entries are read before any insertion; status reads do not create absent entries; overview aggregation uses a consistent deferred WAL read snapshot with non-creating entry lookup. Write/publication transactions still use BEGIN IMMEDIATE by default. No credential, API permission or cloud mutation behavior changed. Verification passed: real worker process round trip with serialized profile/cache bindings; archived-code before/after failure comparison; writer contention including missing collections with SQL trace confirming no INSERT/UPDATE/DELETE/BEGIN IMMEDIATE; subsequent successful cache publications; summary paging/isolation/partial/legacy cases; cache recovery; real connected Coordinator/ResourceInventory route; operation journaling and 34 actual-SDK cases; Python/source manifests. Build limitation: the existing packaged executable itself cannot start on this harness because its bundled math extension requires GLIBC_2.44. Archived application code was therefore executed with the compatible host Python runtime; this is not a successful native packaged-runtime test. The GLIBC mismatch is not claimed as the cause of the reporter's subnet error. The matching contention failure is now confirmed and fixed in source. The issue remains open pending a rebuilt desktop app and reporter/native runtime confirmation.

Alex referenced this issue from a commit

2026-11-05 19:39:34 +01:00

Align network summary panels and show partial subnet inventory

Alex referenced this issue from a commit

2026-11-05 19:39:34 +01:00

Keep network summary and status reads off the SQLite writer lane

Alex closed this issue

2026-11-05 19:40:10 +01:00