Repository navigation
Normal GUI cold connect stops a preparing runtime before readiness; use existing exact-owner async startup lifecycle #355
Description
GUI synchronous cold connect stops before catalogue readiness
Parent OpenHCS integration owns diagnosis and follow-through. Observed on own
private installed0.8.7, source8119577 and again merged901e9a49, isolated display91,
configured loopback execution5993/6993, UI5994. No provider/data/Fiji download.
The normal GUI startup path calls PlateManager.ensure_execution_server through
the ZMQClientService's synchronous ATTACH_OR_START bridge. It starts the child,
reports catalogue/preparation activity, then returns False and stops the exact
child before a cold catalogue is ready. Current private backing ZMQRuntime
client.py::_connect_locked (spawn/wait block around1060..1116) explicitly
calls process.stop and endpoint.cleanup when _wait_for_endpoint_ready returns
None. The UI traceback ends "Failed to connect to ZMQ execution server".
The child is authoritatively absent afterward; it was not inferred from timeout.
The exact initiating budget/observer defect remains to be isolated before a fix.
Counterexample: existing exposed openhcs_start_owned_runtime starts the same
explicit pair promptly with an exact PID+creation-time handle; observation stays
read-only. Child1168146/create1790850562.06 reaches native readiness in about109s,
with266callables and continuous preparation receipts. No deadline increase,
restart of a live child, foreign adoption or scientific replay. Original complete
handle is ui349-installed-20261001/owned-runtime-handle.json. This is a separate
engineering runtime, not a continuation of the frozen blind trial.
Keep the original GUI startup failures/logs and successful owned-runtime journal.
Extend the existing lifecycle/readiness owners, preserving their exact incarnation,
cancellation and terminality guarantees. Do not merely increase timeout or copy
bootstrap/process management into the GUI. Acceptance: fresh empty-cache normal
GUI startup stays responsive, preserves one child while actual startup activity
continues, and attaches after readiness; cancellation and truly stalled/terminal
negative controls remain bounded. Verify actual installed GUI/MCP entrypoints.
No fix or fresh-GUI acceptance is claimed in this issue checkpoint.
Activity
trissim commentedon Oct 1, 2026
The ordinary benchmark entrypoint also reproduces the cold-start cancellation problem in a fresh source checkout, so this issue affects performance qualification as well as the GUI.
On clean
5d1f1a781eda851b4783b68db342b76eeef9dea9(which contains current mainc4be92335), two isolated 3D benchmark attempts ended before any pipeline execution. The server was still doing mandatory registry/kernel preparation; after a 15.005s client activity gap the client cleanup cancelled its activefunction_catalog_preparationfuture. The server log ends inCancelledError. Both attempts have zero execution diagnostic regions; their error rows are not performance observations.Original failed artifacts are retained under
/var/tmp/openhcs-minimal-3d-phase-probe-v3-20261001and/var/tmp/openhcs-minimal-3d-phase-probe-v3b-20261001, with controller logs in the external benchmark evidence directory. A longer allowance is being used only for the subsequent diagnostic controller; this is not a production fix or cold-start acceptance. Mandatory startup/prewarming remains excluded from pipeline clocks.The fix belongs to the existing readiness/activity and exact child lifecycle owners, as described in this issue and draft #358. No duplicate issue or competing startup implementation is being opened in runtime-plumbing #394.
Merge pull request #358 from OpenHCSDev/fix/gui-cold-connect-355-2026…