test(dmsg,wasmhv): Tier A headless browser-edge regression gate + mdisc check wss health probe - #3637
Merged
0pcom merged 1 commit intoJul 30, 2026
Conversation
…isc check` wss health probe
Tier A of the wasm-visor testing plan: the browser profile (a wss-only dmsg
client, Carriers=[ws]) exercised headlessly against real in-process dmsg
servers — no browser, ordinary `go test`, CI-gating.
- pkg/dmsg/dmsg/browser_edge_test.go: four e2e regressions locking the
on-demand rendezvous model the wasm visor lives on —
(1) reach a peer delegated to a DIFFERENT server via an on-demand ws session;
(2) NEVER fall back to TCP: peer's first delegated server is tcp-only (live,
dialable — the pre-skycoin#3634 fallback would connect to it, a capability
violation that manifested in browsers as futile `dial tcp` → dmsg error
202) — the dial must skip it cleanly and rendezvous via the next server,
ending with ws-only sessions;
(3) a peer ONLY on a tcp-only server is honestly unreachable (clear error,
no sneaked tcp session);
(4) ConnectToAllServers (skycoin#3632) honors the carrier contract per server: ws
servers connect, the tcp-only one lands in Failed.
- pkg/dmsg/dmsgclient/fallback_disc_test.go: AllServers prefers the LIVE
discovery (a seeded edge must learn the whole deployment, not stay pinned to
its 2 seeds) with seed fallback on failure/empty; AvailableServers stays on
the direct client (boot path never blocks on a not-yet-reachable discovery).
- pkg/wasmhv/self_test.go: the wasm core's POST /dmsg/connect-all route
(404'd before skycoin#3632) returns the DmsgConnectAllResult shape; GET is 405.
Plus the operator-requested deployment probe that would have auto-caught the
2026-07-30 wss breakage (2 stale DNS records at a dead shared proxy + 1 failed
cert issuance):
- `skywire cli mdisc check`: probes every discovery server's advertised
AddressWS — DNS resolution vs the server's own address (warning; shared
fronts are legitimate), then a plain HTTP/1.1 GET with normal TLS
verification expecting 426 Upgrade Required. Exits nonzero when an
advertised front doesn't serve. dmsg:// discovery URLs go through the CLI's
resolving fetch (local visor); http(s):// is fetched directly (CI).
Live run against the deployment: 9 servers, 0 failing.
- .github/workflows/deployment-health.yml: scheduled (6h) + manual probe via
the clearnet discovery mirror.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XzckVqHX624RpdEWcvVosA
This was referenced Jul 30, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Tier A of the wasm-visor testing plan
The browser profile — a wss-only dmsg client (
Carriers=[ws]) — exercised headlessly against real in-process dmsg servers: no browser, ordinarygo test, CI-gating. Locks everything the recent reachability campaign fixed:pkg/dmsg/dmsg/browser_edge_test.go— 4 e2e regressions on the on-demand rendezvous model:dial tcp→dmsg error 202); the dial must skip it cleanly and rendezvous via the next server, ending with ws-only sessions;ConnectToAllServers(fix(wasm/dmsg): robust on-demand rendezvous — browser never falls back to TCP (+ live server discovery) #3632) honors the carrier contract per server (ws connect; tcp-only lands inFailed).pkg/dmsg/dmsgclient/fallback_disc_test.go—AllServersprefers the live discovery (seeded edge must learn the whole deployment, not stay pinned to 2 seeds), seed-fallback on failure/empty;AvailableServersstays direct (boot path never blocks on a not-yet-reachable discovery).pkg/wasmhv/self_test.go— the wasm core'sPOST /dmsg/connect-allroute returns theDmsgConnectAllResultshape;GET→ 405.skywire cli mdisc check+ scheduled CIThe operator-requested probe that would have auto-caught the 2026-07-30 wss breakage (2 stale DNS records pointing at a dead shared proxy + 1 failed cert issuance). For every discovery server's advertised
AddressWS: DNS cross-check vs the server's own address (warning — shared fronts are legitimate), then a plain HTTP/1.1 GET with normal TLS verification expecting 426 Upgrade Required; exits nonzero when an advertised front doesn't serve.dmsg://discovery URLs use the CLI's resolving fetch (local visor);http(s)://is fetched directly (CI). Scheduled workflow (deployment-health.yml, 6-hourly + manual) probes via the clearnet mirror.Live run against the deployment right now:
9 servers, 0 advertised wss fronts failing✓golangci-lint0 issues; all suites green.