Rust mode: subc `module_warming` / `target_unavailable` route refusals classify as fatal instead of transient

[iceteaSA]

Summary

SubcModuleTransport classifies route/request failures with three closed allow-lists. Daemon 0.17.20 can answer route.open with module_warming during a module's pre-HELLO respawn window (subconscious #53), and neither module_warming nor target_unavailable appears in any of the three predicates. Both therefore fall through to the bare throw error, skipping the retry-once-on-fresh-generation path and pushing the caller straight into its LKG/raw fallback ladder.

Fail-safe, not corrupting — but it burns the pass and can park a session for a condition that resolves on its own within a second or two.

Verified against dc952bf3 (packages/plugin/src/hooks/magic-context/module-transport.ts).

The three predicates

predicate	line	accepted codes
isStaleOrDeadRouteFailure	92-110	stale_route_handle, route_closed, unknown_channel, unrecognized_channel, route_gone (+ StaleRouteHandleError, two message regexes)
isDeadlineFailure	112-120	ETIMEDOUT, request_deadline, deadline_exceeded_no_drop_observed (+ SocketTimeoutError)
isConnectionFailure	122-…	ENOENT, ECONNREFUSED, ECONNRESET, EPIPE, … (+ socket/stale classes, isConsumerReconnectTransient)

$ git show upstream/master:packages/plugin/src/hooks/magic-context/module-transport.ts \
    | grep -c -e module_warming -e target_unavailable -e module_unavailable
0

Path

module-transport.ts:652-672 — a refusal that satisfies none of the predicates reaches throw error at 672:

if (isConnectionFailure(error)) {
    …
    // Retry once on a fresh connection generation before the caller enters its
    // LKG/raw fallback ladder.
    if (attempt === 0 && !args.signal?.aborted) continue;
}
throw error;   // ← module_warming lands here

module_warming is precisely the case the comment above it describes: a condition where retrying on the next tick is correct.

Why it matters now

The respawn window is exactly when this fires: ck module restart magic-context drains and re-registers in ~130ms, and any route.open racing that window gets module_warming rather than a socket error. A classifier keyed on the pre-#53 {unknown_module, unknown_channel} pair misses it — this is the same class AFT's TS bridge fixed in its #255.

Suggested fix

Add a transient-refusal predicate covering module_warming and target_unavailable, routed to the same retry-next-generation arm rather than the fatal one. Worth treating the code set as open rather than closed: an unrecognised refusal code from a newer daemon is more likely transient than fatal, so defaulting unknown codes to one bounded retry would keep this from recurring on the next protocol bump.

Disclosure

Found by reading, not from a live failure — this seat runs transform_mode: "ts", so the path is dormant here and I have no repro trace. Surfaced via a fleet lens from Prefrontal (prefrontal#48) after AFT hit the same class. Line refs are against dc952bf3.

[iceteaSA]

Correction from the reporter — the practical claim in this issue is wrong

I filed this after reading MC's classifier without checking the layer beneath it. Having now read the pinned SDK, the central claim ("a route.open refusal carrying module_warming reaches the fatal throw") does not hold, and I'd rather say so than let someone spend a fix on it.

What I missed. packages/plugin/package.json pins @cortexkit/subc-client at 0.11.1, and that version already handles this internally:

• clients/subc-client/src/client.ts:1707 exports isRetryableRouteOpenCode, kept byte-identical to subc-client-rs's is_retryable_route_open_code and conformance-tested against crates/subc-protocol/tests/golden/decision_tables.json.
• client.ts:1144 applies that predicate to route.open failures and retries in-place, bounded only by ROUTE_OPEN_RETRY_DEADLINE_MS = 30_000 (client.ts:82). The doc comment is explicit that the deadline is the sole binder, deliberately replacing an earlier attempt cap that capped patience at ~3.1s.
• The golden table classifies module_warming, target_unavailable, unknown_module, module_reloading, and module_timeout all as retryable.

The respawn window this issue is about is ~130ms (ck module restart magic-context drains and re-registers in that time). Against a 30s in-SDK retry deadline, the refusal is absorbed well before MC's classifier is reached. And in the case where it does escape — a module still warming after 30 seconds — falling through to the LKG ladder is defensible behavior, not a defect.

What still stands, at lower severity. The three predicates in module-transport.ts are closed allow-lists that duplicate classification the SDK already owns, and any code outside them defaults to fatal. That's a robustness/duplication point rather than the live bug I described.

Better fix than the one I originally proposed. Rather than adding a local transient-code list (which would be a third copy of the same table), call the SDK's exported isRetryableRouteOpenCode. It is generated against the shared decision table, so it tracks protocol additions automatically instead of needing a manual edit on each bump. Credit to CortexKit Hub for pointing at the decision-table approach; verifying it is what surfaced that the TS side already ships the predicate.

Happy for this to be closed, or retitled to the narrower "classifier should consume the SDK's shared decision table instead of local allow-lists" — maintainer's call. Apologies for the noise; I should have read the SDK before filing.