Repository navigation
Verify desktop history capture and restore after thread-local serialization repair #169
Description
Owner: OpenHCS blind-analysis coordinator (current integration owner for #153). Reproducer: old H001 GUI on isolated display :89, PID 608239, UI bridge descriptor mcp_outputs/haase_blind_20260927/trials/H001/ui_bridge.json. Through public MCP, invoke main_window/restart_session with explicit confirmation, then observe the same operation receipt. Operation 6633ef33-d5e5-47e8-9e4a-238234830870 reaches completed with outcome rejected, main_window_action_failed, TypeError: cannot pickle _thread._local object. GUI remains alive. No retry or forced close has been issued.
The action writes a complete declaration snapshot first, then ObjectStateRegistry.save_history_to_file fails and the failed capture directory is discarded by the existing fail-closed cleanup. A separate export preserves current declarations, but is not the full undo/history. H003 on :88 successfully captured its complete history through the same action and is archived under /home/ts/wt; the H002 viewer and original science files remain unchanged.
Acceptance: identify the nominal owner introducing the thread-local runtime handle into retained H001 history; separate durable declaration/history state from that runtime ownership without permissive pickle fallbacks or history dropping. Prove a continuous live session capture/restoration with original current declarations and retained undo/history, then safely close the retained old H001 GUI. Source, focused tests, and live preservation must be reported separately. Keep original in-memory state alive until a history-safe route or explicit owner disposition is available.
Activity
trissim commentedon Sep 29, 2026
Update after explicit owner disposition: Tristan chose “Export current declarations and close it”, accepting loss of H001’s in-memory undo/history. The complete current configuration/pipeline was exported through public MCP to /home/ts/wt/openhcs-closed-agent-sessions-20260929/H001-current-declarations.py (3472 bytes including a normalized final newline; SHA-256 061e6a64b58d519b155db842740d372ef91cfd014e5e39bf095e9e580da28e9d). This is not a full-history backup.
Public MCP main_window/exit receipt 3d523548-a6a4-47f1-bd33-c07dac81ba99 was accepted. H001 GUI PID 608239 and execution worker PID 609055 are absent, and openhcs-h001-gui4.service is inactive/dead with Result=success. Saved science files, desktop :0, and current H002 GUI/viewer :90/TCP5690 remain untouched; the latter processes were verified alive.
The serialization defect is NOT fixed. I retain ownership of investigating the thread-local runtime handle in durable history and verifying a live full-history capture/restore; cleanup no longer depends on keeping this old H001 process alive.
trissim commentedon Sep 29, 2026
Implementation owner: Linnaeus, coordinated with the paired #131/#169 memory/session-durability work. An isolated branch is active under
/home/ts/wt; a draft implementation PR will be linked after the first working checkpoint. Suspected retention remains unproven until a bounded real-MCP measurement distinguishes request growth from baseline import/cache footprint. Integration owner is the OpenHCS coordinator.Merge pull request #208 from OpenHCSDev/fix/memory-session-20260929
Plan remaining MCP, CZI and desktop receiving acceptance (#131, #132, #…
trissim commentedon Oct 6, 2026
Current-main audit (6 October): the original thread-local serialization cause is implemented, not an outstanding source patch. Main d1cc443 pins ArrayBridge1e53d03d; its ThreadGPUContext owns runtime thread-local storage on the importable class, rather than pulling the handle into unpublished decorated-function globals. Current tests/unit/pyqt_gui/test_durable_decorated_history.py exercises the actual ObjectStateRegistry and PipelineObjectStateBinding: unpickleable runtime handle, historical decorated callable, current declarations, save/load into a fresh registry, undo and return to current state, with callable execution and preserved runtime identity. Original focused evidence is retained in PR208 and docs/validation/memory-session-20260929.md. This issue remains open ONLY for its original continuous installed desktop capture/restoration acceptance; the native test explicitly does not claim that GUI journey. The disposed H001 in-memory history cannot be recovered: Tristan expressly accepted exporting current declarations and closing it. Do not keep calling that old runtime alive or reopen a competing thread-local implementation. This scope is distinct from causal MCP retention issue131.
[-]Desktop session restart fails saving H001 history: cannot pickle _thread._local[/-][+]Verify desktop history capture and restore after thread-local serialization repair[/+]trissim commentedon Oct 6, 2026
The thread-local serialization cause is fixed in the main-pinned ArrayBridge1e53d03d and merged PR208. ThreadGPUContext owns its thread-local runtime storage on the importable class, rather than retaining it in serialized callable globals. The real ObjectStateRegistry/PipelineObjectStateBinding test saves and restores current declarations plus history, performs undo/return, and executes the restored historical callable while preserving runtime identity. The old H001 GUI was closed after Tristan explicitly chose current-declaration export over retaining its unsavable in-memory history. Closing the repaired pickle bug and disposed historical incident. No recovery of that disposed undo history or new installed desktop capture is claimed.