MGS1032: timeout declaration no longer describes the target

magus doctor compared each declared timeout against how long magus recorded the target actually running, and they no longer bracket each other.

advice  timeout declarations
        2 of 5 declared timeout(s) no longer describe the target; a ceiling is only
        a guard while it brackets real runs
        - (workspace root) security declares a 15m timeout and has already run for
          13m0s; the next slow machine fails a build that was fine
        - docs render declares a 12h timeout and has never run longer than 42s; a
          hang would hold its locks that long before anything noticed

Why

A ceiling is a claim about a target, and claims rot. This is the sibling of MGS1030, which keeps memory_mb honest for the same reason and by the same means: magus already records the figure, so the disagreement is a fact it holds rather than a question the author has to think to ask.

Both directions cost something, and they cost different things:

• Crowded: a recorded run has reached three quarters of the ceiling. Nothing is broken yet, and that is the point of reporting it now - the next cold cache or slower machine turns a correct build into a failed one, and a guard that starts failing legitimate runs teaches its author to raise it without reading, which is how a ceiling stops meaning anything.
• Loose: the ceiling is more than a hundred times the longest run on record. The number is not wrong, it has stopped doing its job: a hung target would hold its project locks for most of a day before anything fired.

A hundred times is deliberately far out. A correctly written guard sits well above its measurements - magus's own two declarations run at roughly seven and twenty times their worst recorded run - and a threshold that reported those would be a check nobody reads.

What is not reported

An undeclared target draws silence. Unlike memory_mb, where declaring nothing is measurably harmful because machine-wide admission goes blind, an undeclared timeout is the documented default and costs nothing until a target hangs. And a target that hangs records no duration, so the evidence for the finding does not exist: magus would be arguing from the runs that went fine.

A target that has never run draws silence for the same reason. There is a declaration but no measurement, and inventing a comparison would be worse than saying nothing.

Runs shorter than two seconds are not compared. The noise in one measurement - a cold toolchain, a busy machine - is a large fraction of the figure, so a ratio against it describes the machine rather than the declaration.

Resolution

1. Move the ceiling. For a crowded one, raise it against the worst run on record rather than the typical one. For a loose one, lower it to something a person would actually wait through:

   magus\project({
       "targets": {
           "security": {"timeout": "30m"},
       },
   });
   

2. Fix the target, if the growth is the surprise rather than the declaration. A crowded ceiling on a target nobody made slower usually means it started waiting on something.

3. Leave it alone deliberately. How much headroom a runaway guard carries is a judgment about the worst machine it will ever run on, which magus has not seen. This is advice, never a failure, and nothing will escalate.

See also

• MGS3011: what happens when a target actually exceeds its ceiling.
• MGS1030: the same check for memory_mb.