Intervals and native timers
Version-sensitive native helper contract: TimeInterval schedules its next callback before resolving the weak owner and invoking its method. Owner collection, a missing method or a method exception does not cancel that successor. Explicit stop remains necessary. Removing the last listener from TimeIntervalEvent stops its interval; clearing an unrelated container is not equivalent.
Python timers recompute from finishTime minus serverTime. A zero snapshot can be published before a later negative tick hides the view. Hide stops the interval but can retain the view; clear stops/releases without invoking the hide hook. An already-expired timer can show without starting a tick. Keep display removal, cancellation and reference release separate.
Replacing a timer without stopping it can leave its interval scheduled after the weak owner disappears. That prevents old view writes but does not stop background callbacks. Explicitly cancel a replaced timer rather than relying on owner collection.
Notifiers and prerequisite latches
Scheduled notifiers consume a relative-delay function; they do not choose an epoch/server clock. A false/zero delay can schedule nothing instead of an immediate catch-up update. The base repeating notifier can rearm after its update even if stop was called from inside it; standalone clear releases functions without cancelling a pending callback. Use the owning stop-then-clear lifecycle and perform initial state delivery explicitly.
MethodsRules delayable calls are prerequisite latches, not timers or completion futures. A prerequisite returning False can still release queued calls after normal return; retained arguments are not snapshots. Draining is synchronous, and a raised queued call can lose the remainder of a popped batch. Inspect the concrete controller reset override before assuming pending work survives a non-leaving clear.
See Native Async Lifetimes for future cancellation and state versus countdown for consumer semantics.
A period gate limits admission, not async completion
oncePerPeriod stores its last admitted wall-clock time in a closure created by the decorator factory. All instances using that decorated method share the gate; reusing the same returned decorator for multiple functions also shares it. Admission requires a strictly greater elapsed period. A skipped call is dropped, without a timer, queued retry or trailing update.
The timestamp changes before the body runs, including when it raises, and the wrapper discards its return value. When placed outside adisp_process, it limits starts rather than waiting for the generator to finish. A later call can pass the period gate while earlier work remains pending. Use separate owner-scoped busy/result state when overlap matters; do not treat this helper as per-instance debounce or an operation-completion lock. These are version-sensitive Python scheduling rules, not measured UI or request timing.
Waiting captions belong to the GUI decorator object
The GUI adisp_process decorator stores its current caption and remaining-message list on one decorator object. Calls through the same decorated method, including different bound instances, share that state. Entry and callback progress advance the shared sequence; normal generator exhaustion hides the current caption and resets it.
Overlapping calls can consume each other's caption state or issue a hide while another invocation is pending. That describes helper calls, not guaranteed widget visibility under other Waiting owners and UI policy. The wrapper has no exception-finally reset; an escaping initial or resumed error can leave shared state behind. Inspect operation-level serialization and cleanup separately before reusing this wrapper. These source and recording-callback findings do not establish actual overlapping exchanges, purchases or visible UI failure.