Product loading can expose an internal chainHead error instead of reconnecting

[replghost]

What users see

During product loading, a reload can end at:

Domain can't be reached

chainHead follow stopped (cause: ChainHead stopped)

This is an internal light-client error and should not be shown to users. Dotli should reconnect once and continue loading, or show a user-facing connectivity error if reconnection also fails.

Scope

This is a generic resolver recovery problem. It is not specific to a product: the affected retry wrapper serves Dot-name, owner, executable-manifest, and root-manifest resolution.

The self-contained fix is isolated in #229 against main; it does not depend on #185 or application runtime behavior.

Diagnosis

A chainHead subscription can stop when its connection or chain session resets. Dotli should retry once on a replacement resolver generation.

The protocol bridge discards the remote error discriminator, while the recovery check needs to distinguish the typed ApiStoppedError. The stopped response is therefore treated as an ordinary terminal error and reaches the page.

Fix

• preserve typed error discriminators across the iframe and SharedWorker protocol bridge;
• retry ApiStoppedError once for generic resolver requests;
• retain compatibility with the older wrapped error;
• keep a second stopped response and unrelated errors terminal;
• cover successful recovery and retry exhaustion with browser regressions.

[replghost]

The fix is now isolated in standalone PR #229 against main. It preserves typed protocol errors and retries a stopped generic resolver request once, with browser coverage for successful recovery and retry exhaustion. The same behavior remains present on the deployed #185/#226 stack.

[replghost]

Deployed to westendli.dev at 87c176d. Deployment run 34432725653 passed its quality gate, deployment, and all 7 live product smokes without exposing the internal chainHead message.

[johnthecat]

Closed in #313, #320