0.5.209: after a successful with-AI login the client re-enters the post-setup "holding reconfiguring state while the node restarts" and never leaves Login (macOS)

[emooreatx]

With-AI path, macOS, ciris-client 0.5.209 + ciris-server 0.5.203 — run #34223901074, per-launch log ciris_desktop_setup.20260908T121405.log (the with-AI session; the login leg drives the same process).

The with-AI setup pass is green (ai_configuration, setup_complete, announce_bundle 3/3). Our login leg then finds the Login screen (the "Setup is complete. Your node restarted, so please log back in" variant), types the credentials, clicks Login — and the client authenticates:

[CIRISApiClient] [login] Login successful: userId=wa-root-qa-node-…, role=SYSTEM_ADMIN
[CIRISApp]       [DEBUG][Screen.Setup] Rendering setup screen (hasAgent=true)
[StartupViewModel] [STARTUP][WAIT][26457ms] All 1 services already loaded, skipping wait
[StartupViewModel] [STARTUP][READY] Phase set to READY
[CIRISApp]       Startup READY, checking first-run status...
[CIRISApp]       [INFO][gate] clientMode=AGENT (role=agent, cognitive_state=work, services=9, folded=true, reachable=true)
[CIRISApp]       Setup complete — holding reconfiguring state while the node restarts
[StartupViewModel] [STARTUP][STATUS] Restarting your node...

…and then stays on Login for the rest of the budget; /screen answers Login for 30 s and the screenshot shows the same screen with the credentials still filled. Nothing restarted: this is the agent on :8080, alive and in work, and the client's own gate line says so one line earlier.

So after a successful login the client falls back into the post-setup branch — "holding reconfiguring state while the node restarts" — which is the hand-off handling from #43 (0.5.209's ff8ffe0c4), applied to a session where run-without-AI was never recorded and the node never went away. On 0.5.208 this leg passed on macOS, and on this same run the identical leg passed on Windows, so it looks like state carried from the setup session into the login rather than a deterministic path — the login happens in the process that just completed setup, and something still says "setup just completed".

What I would expect: a successful login navigates to Interact (or Setup if first-run) regardless of what the previous screen's completion state was; the "node restarts" hold belongs only to a session that recorded the flag. Not prescribing the mechanism. Related: #43 (the two hand-off behaviours on the no-AI path); this is the with-AI path.

[emooreatx]

Fixed on main at 7b1afec. Your read was right — state carried from the setup session into the login — and the mechanism is a latch plus a cancellable effect.

What happens

reconfiguring is a latch: set once when setup completes, cleared only by whichever branch routes out of the hold. But the hold lives inside LaunchedEffect(phase), and every setPhase() cancels that effect mid-poll — the code even carries a warning about it a few lines down:

// Re-assert the stable status … do NOT setPhase() here, that would
// cancel this LaunchedEffect.

A cancellation leaves the latch set with nothing having routed. The next phase change re-enters the hold at the top, and when that lands after the owner has signed back in, the client holds "Restarting your node…" over a working session — your Phase set to READY line is the re-entry, one line after the gate says clientMode=AGENT … cognitive_state=work.

That is also why it passed on Windows and failed on macOS in the same run: it is a race on when the phase moves relative to the hold's poll, not a path either build takes deterministically. So I would not call it a 0.5.209 regression in the strict sense — the latch and the cancellable hold both predate it — but any timing change can expose it, and 0.5.209 changed timing.

The fix

A live session ends the hold. A session is exactly the evidence the hold exists to gather: it proves the backend came back and that the owner can talk to it. Holding one makes the hold moot however we got there.

Guarded at the reader, not at the writers — the latch has one reader and eight places that set a token, and guarding the reader makes it true by construction rather than by eight call sites remembering. Same reasoning that put the node URL behind one resolved value instead of thirty call sites.

The decision is now a predicate next to hasAiStep and initialSetupMode, because those live outside Compose and can be tested while the effect cannot:

fun shouldHoldForReconfigure(reconfiguring: Boolean, hasSession: Boolean): Boolean =
    reconfiguring && !hasSession

Its test states the rule as a property over both latch values, so a later edit cannot quietly make the latch sufficient again.

Your expectation — "a successful login navigates to Interact regardless of what the previous screen's completion state was" — is what this implements. One refinement on the second half: the hold is not only for the no-AI path; the with-AI reload rebinds :4243 too, and the hold is right for that. What it must never outlive is a session.

691 shared tests green; desktop, Android and wasm targets compile; gates clean.

Not in a published version. 0.5.210 is publishing now and does not contain this — it carries the :43 API-client completion. I will fold this into the next cut and say here when it is out.

[emooreatx]

0.5.211 is on PyPI with both of these fixed — all five wheels and the Android AAR are published. pip install ciris-client==0.5.211.

One caveat so you do not pin the wrong thing: the iOS XCFramework is still building (~2.5h) and attaches to the GitHub release when it lands. Also, 0.5.210 has no XCFramework at all — I cancelled its iOS job to free runners for this cut, after its wheels had already published. So for iOS artifacts, wait for v0.5.211's release assets; do not fall back to v0.5.210.

What 0.5.211 carries for you:

• 0.5.209: a waitForServices timeout is thrown on the main thread and kills the app (Android FATAL EXCEPTION; iOS SIGABRT) after the run-without-AI re-point #47 — the timeout is an error state, not a throw, fixed inside waitForServices so it cannot depend on which caller ran it. And the roster wait is skipped entirely when ActiveBackend names the node, so there is no 22-service count to time out on after the hand-off.
• 0.5.209: after a successful with-AI login the client re-enters the post-setup "holding reconfiguring state while the node restarts" and never leaves Login (macOS) #46 — a live session ends the post-setup hold, so a successful login is no longer thrown away by a re-entered "Restarting your node…".
• Everything from 0.5.209 and 0.5.210: the backend switch actually wired, and the API client moving with it rather than only the node URL.

Expected on your side: the three desktop no-AI legs clear, Android no-AI login passes in-session against the fold, and no fatal exception on either phone. Android reset should still fail on CIRISServer#563 — that is the split-key node-only boot and is neither of ours; a red reset leg there is not any of these issues reopening.

If something is still red, the response text is worth pasting verbatim now: /scroll reports offsets, refusals name what is drivable, and the backend line at startup says which port the client chose ([BACKEND] serving on :4243/health).