Module hooks 

The two hook-timeout ceilings, as two types that cannot be swapped.

Two families of lifecycle hook with ceilings 60x apart:

• run, resume, suspend, terminate — max 60 seconds. These wait on a daemon that is already booted, so 60s is generous and a daemon slower than that fails the launch with no way to ask for more time.
• ready, validate — max 3600 seconds. These are image-build hooks; a build hook waits on a Dockerfile.

Both from the pinned service model (MicrovmHooks*TimeoutInSecondsInteger and MicrovmImageHooks*TimeoutInSecondsInteger, API version 2025-09-09), checked against it by the build gate (TRAP-12).

Why two types rather than one with a comment

Because the trap is the confusion, not the number. A caller who picks one value large enough for a build hook — 300, say — passes image validation and is rejected on the run family, after the artifact upload, reported as a constraint on a field they did not know had two different ceilings. Runtime validation rejects an out-of-range value only after it has been assigned to a hook family.

Here each ceiling is its own type, so a build timeout in a run-hook field is a compile error. There is deliberately no conversion between them — no From, no as_run(), no shared trait with a secs() method that a generic function could use to launder one into the other. A conversion is the whole trap with an extra step: BuildHookTimeout::try_new(300)? is valid, and if it could become a RunHookTimeout the 60s ceiling would be enforced nowhere.

The only thing both types offer is a way out to a plain integer, at the wire boundary where the request body is built and the field name already says which family it is.

Structs

BuildHookTimeout

A timeout for the ready or validate image-build hook: 1..=3600 seconds.

RunHookTimeout

A timeout for the run, resume, suspend, or terminate hook: 1..=60 seconds.

Functions

require_hook_port

A hook port: 1..=65535 (HooksPortInteger).