HyperProcess::new documents a 30s callback timeout but waits 60s

Read hyperdb-api/src/process.rs:226 and wait_for_callback at line 709, then check CI for the reported slow hyperd startup. Decide whether 30 or 60 seconds is the intended contract, align the documentation and implementation, and consider a documented const so they cannot drift; done means the public timeout and actual wait agree.

Summary

HyperProcess::new's doc comment promises a 30-second timeout for Hyper's connect-back callback, but the implementation waits 60 seconds.

The documented contract:

/// - Hyper doesn't connect back within the timeout (30 seconds)

— hyperdb-api/src/process.rs:226

The actual wait, in wait_for_callback:

let timeout = Duration::from_secs(60);

— hyperdb-api/src/process.rs:709

Why it matters

A caller sizing their own timeout or retry budget against the documented 30 seconds will be surprised by a failure path that takes twice as long. It matters most on a slow or loaded host, which is exactly when the callback is slowest and when a caller is most likely to be relying on the documented bound.

The doc comment is the public contract, so this is a defect in one of the two — either the doc understates the wait, or the implementation waits longer than intended.

Fix direction

Decide which value is correct and make the other match:

• If 60 s is the intended behaviour, update the doc comment.
• If 30 s is intended, change the constant — but check CI first. hyperd startup has been observed taking "10+ seconds under load" on CI runners, so halving this bound could introduce flakiness on the slowest legs. That argues for correcting the documentation rather than the constant, but the value should be a deliberate choice rather than an accident.

Either way, consider naming it as a const with a doc comment so the two cannot drift again, and referencing that constant from HyperProcess::new's docs instead of restating the number in prose.

Provenance

Noticed incidentally while auditing hyperdb-api's process lifecycle for the shared-daemon design exploration (#293). Verified against main at 6cfe312.