State Tool: forward platform JWT + version User-Agent on the build-log-streamer WebSocket

[antoine-activestate]

Summary

Makes the State Tool identify itself on the build-log-streamer WebSocket Upgrade so the server can authorize the stream and monitor connecting client versions.

1. Platform JWT via Sec-WebSocket-Protocol. When authenticated, the client offers bearer.<jwt> alongside the real subprotocol build-log-streamer.activestate.com.v1 (which the server echoes back; its allow-list contains only the real one, so the token never appears in the upgrade response). The browser WebSocket API can't set custom request headers, so the dashboard carries the JWT the same way — both clients stay symmetric.
2. Versioned User-Agent on the Upgrade (constants.UserAgent) so the server can see which State Tool versions are connecting.

Design note

The token is threaded as a plain string (prime.Auth().BearerToken() → runtime option → Connect), so pkg/runtime gains no dependency on the authentication package. Empty token = anonymous (unchanged behavior).

Test plan

• go build + gofmt clean across touched packages.
• Real-handshake test against an httptest WebSocket server asserting the offered subprotocols, the negotiated subprotocol (token never echoed back), and the User-Agent the server receives. go test -race clean.

Note

Full server-side JWT validation ships separately (infra repo); this client change degrades gracefully against the current server — an unknown subprotocol is ignored and anonymous still works.

Supersedes #3808 (closed when its branch was shortened to fix a macOS/Windows integration-test socket-path overflow).

[Copilot]

Pull request overview

This PR updates the State Tool’s build-log-streamer WebSocket connection to forward identifying/auth data during the HTTP Upgrade so the server can authorize streams and monitor client versions.

Changes:

• Thread a platform JWT through runtime setup into build-log streaming, and offer it via Sec-WebSocket-Protocol as bearer.<jwt> alongside the real subprotocol.
• Send the standard, versioned User-Agent on the WebSocket Upgrade request.
• Add a new handshake-focused test that validates the server receives the expected Sec-WebSocket-Protocol and User-Agent headers.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
pkg/runtime/setup.go	Adds Opts.AuthToken and passes it into build-log streaming initialization.
pkg/runtime/options.go	Introduces WithAuthToken runtime option for forwarding the platform JWT.
pkg/runtime/internal/buildlog/buildlog.go	Stores the auth token on BuildLog and forwards it into the WS connect call.
pkg/platform/api/buildlogstream/streamer.go	Updates Connect to set subprotocols (including optional bearer.<jwt>) and send the versioned User-Agent.
pkg/platform/api/buildlogstream/streamer_test.go	Adds tests performing a real WS handshake and asserting request headers received by the server.
pkg/platform/api/api.go	Extracts package-level UserAgent() for reuse by the WS dialer.
internal/runbits/runtime/runtime.go	Wires prime.Auth().BearerToken() into runtime options via WithAuthToken.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

[mitchell-as]

I enabled the "critical" integration tests. We don't care so much about the ARM tests because those are expected to fail (we don't have any ARM Platform projects). However, I am seeing some concerning failures:

• TestInstallIntegrationTestSuite/TestInstall (https://github.com/ActiveState/cli/actions/runs/26777933678/job/78934406904?pr=3809#step:27:1192)
• TestRuntimeIntegrationTestSuite/TestInUse (https://github.com/ActiveState/cli/actions/runs/26777933678/job/78934406904?pr=3809#step:27:1833)
• TestRuntimeIntegrationTestSuite/TestRuntimeCache (https://github.com/ActiveState/cli/actions/runs/26777933678/job/78934406904?pr=3809#step:27:2049)

State Tool for the most part runs unauthenticated. This is by design.

[antoine-activestate]

Dug into the three critical-suite failures — they're pre-existing, not introduced by this PR.

The scheduled (nightly) integration suite on master has been red for ≥16 consecutive nights (back through at least 2026-05-17). The most recent nightly — Jun 1 01:04 UTC, on unchanged master, before this PR's latest push — fails on the identical TestInstallIntegrationTestSuite/TestInstall with Build expr for the commit not found: Error retrieving commit … for project ActiveState-CLI/small-python, authentication may be required.

That's a buildplanner dependency-resolution failure (state install → stage commit), which runs upstream of the build-log streaming this PR touches. My only addition to that path is prime.Auth().BearerToken() — a pure getter with no side effects — and the unauthenticated path is unchanged (empty token → anonymous, as today). So this PR doesn't introduce these.

I'm raising the busted nightly as its own issue so it gets a dedicated fix (it looks platform-side — build-expr retrieval for the small-python test commit). The ARM failures are expected per your note.

[antoine-activestate]

Post-deploy follow-up on this matrix. The platform-side buildplanner fix that was producing Build expr for the commit not found since mid-May landed in prod earlier today. On a fresh re-run of this PR's matrix (run 26778768851):

job	result	Build expr… / Could not stage… count
ubuntu-latest	✅ success	0
ubuntu-24.04-arm	✅ success	0
macos-15-intel	✅ success	0
macos-latest	❌ failure	0
windows-2025	❌ failure	0

Pre-deploy ubuntu-latest baseline (gh run rerun 26778768851 --failed from this morning) was 9 × Build expr for the commit not found + 12 × Could not stage commit. Post-deploy all three buildplanner-side tokens are at zero across the entire matrix.

The two remaining failures are different — both trip the post-test "Found error and/or panic in log file" harness check, but the underlying log lines are unrelated to the staged-commit flow:

• macos-latest — TestInstallSuggest (state install djang) — the suggestion lookup emits [ERR multilog.go:19] Failed to retrieve suggestions: 'Failed to resolve ingredient named: djang'. That [ERR] line then trips the harness scan even though the user-facing suggestion-list flow is the intended one.
• windows-2025 — [CRT multilog.go:24] state-svc errored out: Service cannot be reached: ... ipc server down: flisten connection refused. Looks like the first command after stack startup races the state-svc IPC server. The test apparently survives, but the CRT-level log line alone trips the harness.

Both failure modes existed on every nightly for ~16 days but were masked behind the buildplanner failures. Filed separately on the platform side — pinging via Slack with the ticket reference.

Job logs:

• macos-latest: https://github.com/ActiveState/cli/actions/runs/26778768851/job/80621440252
• windows-2025: https://github.com/ActiveState/cli/actions/runs/26778768851/job/80621440238

[mitchell-as]

The test failures are sporadic and not worth digging into.

[antoine-activestate]

Local post-merge wiring verification on master @ f7e4a3a44. Ran a small in-process test that pulls a real platform JWT from disk via state export jwt, drives the merged plumbing (runtime.WithAuthToken(jwt) → Opts.AuthToken → buildlog.New → buildlogstream.Connect) against a local httptest-style WebSocket server, and inspects what lands on the wire:

field	value
Sec-WebSocket-Protocol offered	bearer.<jwt>, build-log-streamer.activestate.com.v1
subprotocol negotiated (response)	build-log-streamer.activestate.com.v1 — token never echoed
User-Agent received by server	state/0.48.0-SHA…; master
Opts.AuthToken after WithAuthToken(jwt)	populated, equal to the JWT

Closes the "does the option propagation actually deliver the JWT to the wire in the built binary" question, independent of the in-package unit test (which only proved the Connect function itself does the right thing given any token). Production code path is wired end-to-end.