#2408 serve: the device-token poll that returns the token takes 88s, making server-login to ops.swamp-club.com take ~90s

Description

swamp auth server-login --server https://ops.swamp-club.com takes about 90 seconds to complete, even when the code is approved in the browser right away. Almost all of that time is one request: the POST /auth/device/token poll that returns the token. The serve instance held that request open for 88.3 s before responding with 200.

The client and the network are not the cause. Every other request to the server took 120–360 ms round-trip, and opening the browser took 120 ms.

Evidence

Client debug log from a build with per-step timing logs (branch login-timeouts, commit b3559aa5). ops.swamp-club.com is not running that build, so server-timing is "none":

"GET" "/auth/info" -> 200 in 356ms
"POST" "/auth/device" -> 200 in 273ms (poll interval: 5s, expires in: 1800s)
Opening the browser took 120ms
15:21:49.615Z "POST" "/auth/device/token" -> 202 in 120ms
Poll 1 pending after 121ms; waiting 5000ms
15:23:22.897Z "POST" "/auth/device/token" -> 200 in 88280ms
Poll 2 returned a token in 88280ms (93404ms since polling began)
Server login completed in 94159ms after 2 poll(s)

Poll 2 was sent at about 15:21:54.6Z (2026-09-23), 5 s after the code was issued.

Where the time goes

handleDeviceToken in src/serve/device_auth_handler.ts does the following for a successful poll:

1. pollForToken and getUserInfo against the OAuth provider (swamp-club.com). Both share one AbortSignal.timeout(30_000), and a timeout would produce a 500 instead of a 200. So at most 30 s of the 88 s is the provider.
2. mintServerToken, wrapped in withSyncGate. It waits for the sync gate, then does the vault put, definition save, token resource write, pushChanged to the datastore, and a catalog invalidate plus definition read-back.
3. storeAccessToken, another vault put.

That leaves at least 58 s in steps 2–3. The most likely suspect is the sync gate wait. A poller pullChanged can hold the gate for up to POLLER_PULL_TIMEOUT_MS (120 s), and the mint waits for up to GATE_WAIT_TIMEOUT_MS (150 s) before going ahead ungated. The datastore push and the read-back after a catalog invalidate are the other candidates. The pollers do not log pull durations, so the current server logs cannot tell these apart.

Steps to reproduce

1. swamp auth server-login --server https://ops.swamp-club.com --log-level debug
2. Approve the code in the browser as soon as it opens.
3. The poll that returns the token takes about 88 s.

Next step

Deploy the login-timeouts build to ops.swamp-club.com and log in again. That build:

• returns a Server-Timing header (upstream-poll, userinfo, mint, store-access-token, total), which the client prints at debug level next to each request's round-trip time;
• logs on the server how long the mint waited for the sync gate, and a mint breakdown (vault put, definition, token resource, datastore push, read-back).

Environment

• Client: dev build of branch login-timeouts on Linux
• Server: ops.swamp-club.com, OAuth mode