CA setup answers 408 at its 5 s deadline but still completes, and the toast blames the passkey #365

New issue

Open

opened 2026-11-05 09:27:22 +00:00 by kayg · 0 comments

kayg commented

2026-11-05 09:27:22 +00:00

Owner

Found during the J175 mesh SSH proof (#221). On a fresh server, the first "set up host connections" shows "Host connections could not be unlocked. Use an administrator passkey and try again.", yet the setup succeeded: the next add-host works without another setup. Seen three times on dev-02 (infraternal-dev-02-std, aarch64) with fresh --data dirs, built from mesh-ssh-s1-j175. The last run was at fac39e066, which is current dev plus J175.

Evidence (2026-11-05, every /remote/ca/* response logged in the browser; paths and status codes only):

CA_HTTP 09:25:55.999Z POST /remote/ca/status 200
CA_HTTP 09:25:57.486Z POST /remote/ca/status 200
CA_HTTP 09:25:58.545Z POST /remote/ca/bootstrap/start 200
CA_HTTP 09:26:06.089Z POST /remote/ca/bootstrap/finish 408
TOASTS ["Host connections could not be unlocked. Use an administrator passkey and try again."]

The server's CA directory, read afterwards (UTC):

/var/tmp/j175s/data/ca           modified 09:26:08
/var/tmp/j175s/data/ca/active    created  09:26:04

So the setup wrote its state before and after the 408, and finished about 2 s after the client was told it failed. The server log has no error for it. dev-02's load average was about 41 on 10 cores at the time (other jobs), so the finish step took longer than usual.

Why.

crates/infraternal-server/src/ca_http.rs, finish_request: the body read, proof check and administration.bootstrap_finish(...) all run inside one tokio::time::timeout(5 s), and on expiry the handler answers 408. The work behind bootstrap_finish evidently doesn't stop when that future is dropped: the state was committed after the 408.
apps/tracer/src/canvas/addhost/authority.on-demand.ts:12 maps every status except 404/503 to "could not be unlocked. Use an administrator passkey and try again", which blames the passkey for a timeout.

Impact.

The owner is told setup failed when it succeeded, and is asked to retry with "an administrator passkey", although they used one.
More important for review: the HTTP result and the committed CA state can disagree. That is a cancellation-safety question for the CA path. Is a finish dropped at the deadline always either fully applied or not applied at all? Here it was fully applied. A partial write at the deadline would need its own check.

Expected (suggestions, not decided). One of these: the deadline covers only the body read and proof check, not the commit; or the commit runs to completion and its real result is returned; or a 408 means "unknown, check status", and the client re-reads /remote/ca/status before showing an error. Separately, the client message for a timeout should not blame the passkey.

Not fixed in the J175 branch, which is out of scope there.

Found during the J175 mesh SSH proof (#221). On a fresh server, the first "set up host connections" shows **"Host connections could not be unlocked. Use an administrator passkey and try again."**, yet the setup succeeded: the next add-host works without another setup. Seen three times on dev-02 (`infraternal-dev-02-std`, aarch64) with fresh `--data` dirs, built from `mesh-ssh-s1-j175`. The last run was at `fac39e066`, which is current dev plus J175. **Evidence (2026-11-05, every `/remote/ca/*` response logged in the browser; paths and status codes only):** ``` CA_HTTP 09:25:55.999Z POST /remote/ca/status 200 CA_HTTP 09:25:57.486Z POST /remote/ca/status 200 CA_HTTP 09:25:58.545Z POST /remote/ca/bootstrap/start 200 CA_HTTP 09:26:06.089Z POST /remote/ca/bootstrap/finish 408 TOASTS ["Host connections could not be unlocked. Use an administrator passkey and try again."] ``` The server's CA directory, read afterwards (UTC): ``` /var/tmp/j175s/data/ca modified 09:26:08 /var/tmp/j175s/data/ca/active created 09:26:04 ``` So the setup wrote its state before and after the 408, and finished about 2 s after the client was told it failed. The server log has no error for it. dev-02's load average was about 41 on 10 cores at the time (other jobs), so the finish step took longer than usual. **Why.** - `crates/infraternal-server/src/ca_http.rs`, `finish_request`: the body read, proof check and `administration.bootstrap_finish(...)` all run inside one `tokio::time::timeout(5 s)`, and on expiry the handler answers `408`. The work behind `bootstrap_finish` evidently doesn't stop when that future is dropped: the state was committed after the 408. - `apps/tracer/src/canvas/addhost/authority.on-demand.ts:12` maps every status except 404/503 to "could not be unlocked. Use an administrator passkey and try again", which blames the passkey for a timeout. **Impact.** - The owner is told setup failed when it succeeded, and is asked to retry with "an administrator passkey", although they used one. - More important for review: the HTTP result and the committed CA state can disagree. That is a cancellation-safety question for the CA path. Is a finish dropped at the deadline always either fully applied or not applied at all? Here it was fully applied. A partial write at the deadline would need its own check. **Expected (suggestions, not decided).** One of these: the deadline covers only the body read and proof check, not the commit; or the commit runs to completion and its real result is returned; or a 408 means "unknown, check status", and the client re-reads `/remote/ca/status` before showing an error. Separately, the client message for a timeout should not blame the passkey. Not fixed in the J175 branch, which is out of scope there.

kayg referenced this issue

2026-11-05 09:36:29 +00:00

Mesh: SSH over the mesh (D197 M1, D235) #221

No labels

launch-qa

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

kayg/infraternal#365

No description provided.

Rows
Columns