Skip to content

20260815 - Give registration a timeout long enough for the server to answer - #14

Merged
Purple10101 merged 1 commit into
mainfrom
20260815-register-timeout
Aug 15, 2026
Merged

Purple10101 merged 1 commit into
mainfrom
20260815-register-timeout

Conversation

@Purple10101

Copy link
Copy Markdown
Collaborator

Found live against production on 2026-08-15, deploying the first two nodes to api.retina.fm.

What happened

Registration timed out four times at the 5 s default read timeout, and the node held at registering with no token. The server had completed all four — it minted tokens we hung up before reading. The node was unregistered locally and registered four times remotely, which needs an operator to reactivate, since a repeat attempt from a node already holding a valid token returns the same opaque 403 as every other refusal.

Why the default was wrong

Registration is not bounded by our server. The spec has it query Mender while the request is open, so the call waits on a third party's API.

measured
unknown node_id (the fast path we had tested) under 1 s
real enrolled node, first attempt ~14 s
real enrolled node, warm 0.4 s

Only the fast path was ever exercised, because every prior test registered against a mock or an unknown identity.

The change

REGISTER_TIMEOUT_S = (3.05, 30.0), for registration alone. Cloudflare fronts the origin with a 100 s ceiling on its response, so 30 s sits well inside what the edge will wait for.

Being generous costs one slow start once per node lifetime. Being tight costs a node that cannot come up at all — and spends the 5/hour and 20/day allowance discovering that.

Detections are unaffected and keep their much shorter budget: abandoning a slow frame so the next goes out fresh is the whole transport discipline.

Tests

  • Ordering of all three budgets is pinned, so detections cannot drift above the default nor registration below it.
  • The Registrar actually passes it. The default's docstring claimed the must-land endpoints overrode it, and for a long time none of them did — which is exactly how a timeout nobody had chosen ended up on the one request that cannot be retried cheaply.

tools/check.sh and tools/check.sh --tracked both green.

Verified live

Both nodes registered on production and are streaming:

node_id node_ref registration state
ret824685c9 ndefud1o03fxwj9 14 s streaming
ret3773656d nde2dmghfu2w6qy 0.4 s streaming

🤖 Generated with Claude Code

…answer

Found live against production on 2026-08-15, deploying the first two nodes.

Registration timed out four times against api.retina.fm at the 5s default read
timeout, and the node held at `registering` with no token. The server had in
fact completed all four: it minted tokens we hung up before reading, so the
node was unregistered locally and registered four times remotely. Recovering
from that needs an operator to reactivate the node, because a repeat attempt
from a node that already holds a valid token returns the same opaque 403 as
every other refusal.

The cause is that registration is not bounded by our server. The spec has it
query Mender while the request is open, so the call waits on a third party's
API. An unknown node_id is refused in under a second — the fast path we had
only ever tested — but a real enrolled node took roughly fourteen seconds on
its first attempt and under half a second once warm.

So the read budget goes to 30s for registration alone. Cloudflare fronts the
origin with a 100s ceiling on its response, so 30s sits well inside what the
edge will wait for, and being generous costs one slow start once per node
lifetime. Being tight costs a node that cannot come up at all, and spends the
5/hour and 20/day allowance doing it.

Detections keep their much shorter budget and are unaffected: abandoning a
slow frame so the next goes out fresh is the whole transport discipline.

Two tests. The first pins the ordering of all three budgets, so detections
cannot quietly drift above the default or registration below it. The second
asserts the Registrar actually passes the value — the default's docstring
claimed the must-land endpoints overrode it, and for a long time none of them
did, which is precisely how a timeout nobody had chosen ended up on the one
request that cannot be retried cheaply.

Both nodes registered and are streaming: ret824685c9 in 14s, ret3773656d in
0.4s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Purple10101
Purple10101 merged commit c3b1f94 into main Aug 15, 2026
2 checks passed
@Purple10101
Purple10101 deleted the 20260815-register-timeout branch September 6, 2026 15:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant