P285 · Tool use

Wait on a fresh observable predicate

Replace guessed delays with a fresh readiness predicate and a bounded timeout.

Editorially reviewed

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

An export takes different amounts of time under load, and a test needs job-7’s result. A teaching getter initially returns pending, then ready with a result path. A fixed 50 ms delay does not establish completion.

Mechanism

Define readiness as job-7 being ready with a readable result. Call the getter afresh on every observation instead of repeatedly checking a cached pending value. Use an agreed timeout and suitable polling interval, or an event subscription that covers races. Read only after readiness; report failed immediately and report task ID, last state and unmet condition on timeout.

Bad example

Test job-7's export by waiting 50 ms and reading its result file. If it fails occasionally, increase the delay to 500 ms.

Good example

Test job-7's export within a2-second budget, reading current task state each time. Continue only when ready and the result is readable. Fail immediately on failed; on timeout return the last state and missing result. Do not hide failure by increasing a fixed delay. Two seconds is this teaching test's budget, not a service performance promise.

Why the change matters

A fixed delay can be both too short and unnecessarily long. Waiting on fresh task state connects continuation to observed readiness and gives failure an explainable exit.

Observable expectation

A simulated getter returning pending, pending, ready should permit one read after the third observation. Persistent pending times out without reading; failed on the second observation reports failure immediately. Inspect getter calls to catch cached-state checks. These are teaching traces.

Limits

The predicate must match the need: file existence does not establish a finished write, and resources can change after ready. Production may require atomic reads or version binding. Choose intervals and budgets for the workload; tests of timer behavior need a different timing oracle.

Sources and evidence

Read the editorial criteria