[ntdatt812]

⚠️ base-red inherited: #9985

Fixes #11331 (the part that is a bug).

The handshake already reports the port; the client throws it away

/api/v1/ws?handshake=1 returns the live server's real listening port:

live: {
  port: parseInt(process.env.LIVE_WS_PORT || "20132", 10),
  publicUrl: getLivePublicUrl(),
  path: getLiveWsPath(),
  ...
}

useLiveDashboard reads publicUrl and path out of that response — and nothing else:

const publicUrl = sanitizeWsPublicUrl(body?.live?.publicUrl);
if (publicUrl) setHandshakeUrl(publicUrl);
if (typeof body?.live?.path === "string" && body.live.path.startsWith("/")) setHandshakePath(body.live.path);

so the URL keeps the port compiled into the bundle:

return `${protocol}//${hostname}:20132${BUILD_TIME_WS_PATH}`;

NEXT_PUBLIC_* is inlined at build time — which is the whole reason this handshake exists, as the comment right above it says. A prebuilt Docker or npm image has no other way to learn a runtime value. So setting LIVE_WS_PORT moves the server and leaves the dashboard dialling 20132, with no way to correct it short of rebuilding the image. That is the Live disabled — WebSocket disconnected banner in the report.

The change

Read live.port from the handshake too, and resolve the URL in one place (shared/utils/wsPath.ts):

1. an explicit wsUrl from the caller
2. a complete live.publicUrl from the handshake
3. the default URL with whatever port and path the handshake reported

A port outside 1..65535 is ignored rather than producing an unconnectable URL.

Also collapsed the if/else in getDefaultWsUrl whose two branches returned the same expression — it read as a distinction that no longer exists.

Scope — what this does not do

The report also asks the frontend to infer the proxy topology and connect over the origin port with a path prefix. That is already supported through LIVE_WS_PUBLIC_URL, which the handshake surfaces as live.publicUrl and which this PR keeps as the highest-priority source. Guessing a same-origin upgrade instead would break the documented setup, since src/proxy.ts has no upgrade handler on the HTTP port — that is the reason for the "Bug #1 fix" comment this PR preserved. So the fix here is the unambiguous half: a configured port must not be ignored.

Tests

tests/unit/live-ws-url-11331.test.ts — 11 cases:

• a reported port replaces the compiled-in one, host and path untouched
• no handshake data → default unchanged
• 0, 70000, 1.5, "", "abc", null, NaN, {} → ignored
• port and path applied together
• a path that is not a path is ignored
• publicUrl wins over the reported port; an explicit wsUrl wins over everything
• an unparseable default is returned as-is instead of throwing
• deriveLiveWsPath behaviour unchanged

Mutation-checked — dropping the url.port assignment turns 2 red:

✖ uses the port the handshake reports instead of the compiled-in one
✖ applies the port and the path together
ℹ pass 9  ℹ fail 2

tsc --noEmit reports nothing in the touched files; prettier/eslint pre-commit hooks clean.

[Selaygermany]

Looked into the 3 failing checks on this PR (as of commit 913a51e):

• Fast Quality Gates fails with 1 gate(s) failed: file-size. This matches the base-red drift already tracked in 🔴 Release branch not green: release/v3.8.50 #9985 on release/v3.8.50 — this diff only touches 4 small files (+174/-23), so the gate failure doesn't look introduced by this change.
• Build (advisory) — non-blocking by design (name says so).
• dast-smoke — cancelled after ~18min on the "Build CLI bundle" step ("The operation was canceled"), which looks like CI infra flakiness rather than a code issue.

Everything else is green: all 4 unit test shards, Vitest fast-path, "No new ESLint warnings", Docs Gates, semgrep x2, merge integrity, change classification.

The fix itself (sanitizeLiveWsPort + resolveLiveWsUrl in src/shared/utils/wsPath.ts) is well-scoped, validates the handshake-reported port (1-65535, type-checked) instead of trusting it blindly, and ships with 11 passing unit tests covering the sanitize/resolve/edge-case paths.

Per the base-red convention in AGENTS.md, might be worth noting ⚠️ base-red inherited: #9985 in the PR description so reviewers don't chase these 3 as regressions caused by this change.

[ntdatt812]

Thanks — added ⚠️ base-red inherited: #9985 to the body per the AGENTS.md §Base-green convention.

I ran the gate locally to pin down which file trips it, because the mechanism is slightly different from inherited drift. file-size is already base-relative on PR events (#8522, --base-ref $PR_BASE_SHA), so ordinary inherited growth cannot red an innocent PR. What fails here is the test-file sub-check, which is absolute for files that are new relative to the frozen baseline:

$ npm run check:file-size -- --base-ref 7715825cb8cd170f5371c4c4bd5f940b5608f480
[file-size] OK — 161 arquivos congelados, cap 1000 para novos (4380 arquivos verificados)
[test-file-size] 1 test file violation(s) (testCap 1000):
  ✗ tests/unit/guardrails/videoBridgeResultCache.test.ts: 1036 > cap 1000 (arquivo novo acima do limite)

That file is not in this diff — it arrives with the base tip itself:

$ git log --oneline -1 -- tests/unit/guardrails/videoBridgeResultCache.test.ts
7715825cb fix(video): harden visual frame deduplication (#11382)

$ git show origin/release/v3.8.50:tests/unit/guardrails/videoBridgeResultCache.test.ts | wc -l
1039

7715825cb is the merge-base of this branch, so every PR cut from the current release/v3.8.50 tip will carry this failure until that test file is split or given a testFrozen entry. Worth flagging on #9985 / to @diegosouzapw, since the base-relative exemption does not cover it.

The other two are cancellations rather than failures — confirmed from the job API:

dast-smoke        conclusion=failure  →  step "Build CLI bundle" = cancelled
Build (advisory)  conclusion=failure  →  step "Run npm run build" = cancelled

Everything this PR actually changes is green.

[ntdatt812]

The three red lanes here are not this diff.

Fast Quality Gates → file-size is the only real failure, and it fails on the base branch by itself:

$ git checkout origin/release/v3.8.50   # clean, zero changes from this PR
$ node scripts/check/check-file-size.mjs --base-ref c83116e634a054b6ad50d54eb49ac7449615fb2e
[file-size] 1 violação(ões):
  ✗ src/lib/guardrails/videoBridgeRuntime.ts: 1009 > cap 1000 (arquivo novo acima do limite)
[test-file-size] 1 test file violation(s) (testCap 1000):
  ✗ tests/unit/guardrails/videoBridgeResultCache.test.ts: 1040 > cap 1000
EXIT=1

tests/unit/guardrails/videoBridgeResultCache.test.ts is 1035 lines at this PR's base sha c83116e634a0 and 1039 on the current release/v3.8.50 tip — it was over the cap before this branch existed, and neither it nor videoBridgeRuntime.ts is in file-size-baseline.json, so both are measured against the 1000 cap for un-frozen files. It arrived with #11362 / #11382 (fix(video): harden result cache identity and coalescing, harden visual frame deduplication).

This PR touches four files — src/hooks/useLiveDashboard.ts, src/shared/utils/wsPath.ts, tests/unit/live-ws-url-11331.test.ts, changelog.d/fixes/11388-live-ws-handshake-port.md — none of them near the cap and none of them the flagged files.

Build (advisory) and dast-smoke did not fail on their own merits — both logs end at ##[error]The operation was canceled., cancelled after the gates job went red.

Happy to rebase once the two guardrails files are split or baselined, if you'd rather see the lane green before merging.