Completion and cancellation ownership
A worker pool's running flag does not prove job acceptance, live workers or future callback delivery. A stopped submission may only log; stop can discard queued jobs while an active job finishes later. Native job implementations also differ in whether they call completion directly on the worker or explicitly marshal it to BigWorld.callback.
Keep one start/stop owner, bounded work and independently guarded receiving context. Restore busy state on every owned terminal path rather than expecting an abandoned future or discarded job to call back. See Native Async Lifetimes for verified future, adapter, scope and pool contracts.
A shared request slot is not a queue
The current TokenRequester owns one callback and one request ID. Its request body does not use isInProcess() as an admission guard. A second admitted call can replace that slot; response ID/type checks reject stale responses but do not complete the displaced caller. Keep request admission and response correlation separate.
| Signal or action | What it covers | Separate responsibility |
|---|---|---|
isInProcess() | Whether the current callback slot is occupied. | A cooldown wait occurs before slot assignment, so this signal can still be false while a delayed call is pending. |
| Optional request timeout | A timeout installed after that cooldown wait. | It is not an end-to-end deadline covering the delay before admission. |
clear() | Drops the current callback, resets the ID/cache, removes the current repository subscription and cancels the retained timeout. | It does not invoke the dropped continuation, cancel the unretained cooldown wait or reset the last-response timestamp. |
After a cooldown wait the helper compares its captured requester callable with a fresh one. That check is not a general account-generation or destroyed-state guard; a delayed call can still reach the later admission path after a clear. An adapter must define its own stale-owner and terminal-delivery policy rather than equating helper cleanup with completion of every waiting consumer.
Construction determines ownership. getTokenRequester(type) returns a shared module-registry instance per type, as the web factory demonstrates. A current macro consumer checks isInProcess() before requesting instead of treating the helper as a queue. That caller-side check does not make cooldown waits occupy the slot or provide multi-caller fanout. Inspect the actual owner before clearing a shared helper to abandon one operation.
These are version-sensitive Python ownership contracts verified against current public source. They do not establish overlapping production requests, real timeout timing or authentication delivery.
URL deduplication also chooses a request policy
CustomFilesCache groups callbacks by URL alone. The first caller selects the display policy and headers for its processing path; later same-URL callers join that group without supplying a new policy. Differing headers do not create independent requests. For mod-owned work, ensure a deduplication key covers every input that changes the result or admission policy.
showImmediately=True permits cached display while refreshing; it is not a force-download flag. A confirmed uncached request normalizes the remote path to completion mode, whose download-failure branch queues a None result. An immediate-display refresh can release the group without a second notification on failure or unchanged content. Final delivery removes the group before invoking consumers, and a raising consumer can skip the rest. Keep change delivery, refresh completion and per-consumer failure handling distinct. These are inspected Python control-flow rules, not measured transport or callback timing.
Memory publication also precedes persistence. A pending write keeps its first submitted packet; another write for the same pending key is suppressed without updating that packet or recording a later dirty value. Releasing the pending marker does not prove a database write: account/database gates or caught errors can skip persistence without an automatic retry. For mod-owned stores, define write acknowledgement and whether pending work must retain the latest value explicitly; successful asset delivery alone establishes neither.
Server population refresh and freshness
The server population controller queues its first lobby request with delay zero when IS_SHOW_SERVER_STATS permits it. A received response replaces its retained dictionary and emits a zero-argument controller event before scheduling the next request five seconds later. The request callback does not reschedule itself. This is a response-to-next-request delay, not a response timeout or an exact five-second sampling cadence; the inspected owner has no separate missing-response recovery timer.
Account sends the request only outside player-entity changes and forwards received stats through a payload-bearing player event. Keep that event distinct from the controller's no-payload notification. Avatar takeover and disconnect stop the controller's listener and retained timer without clearing its last dictionary. A getter read therefore supplies the last received projection, without fetching or establishing freshness.
getStats() returns formatted values and a presentation type. It requires truthy regionCCU and the non-China display policy even when clusterCCU is present; otherwise the displayed values are '-' with UNAVAILABLE. Equal region and cluster counts select the cluster presentation; differing counts select the full presentation. These display states alone establish neither a zero population nor an outage.
The lobby counter seeds its display, subscribes for changes and removes its handler on disposal. The battle menu reads the retained formatted value on population rather than starting battle polling. Pair an observer's subscription and cleanup; do not introduce another request loop merely to refresh a display or treat retained text as a live sample. This is version-sensitive readable-source evidence only; requests, event delivery, timers, rendering and installed bytecode were not runtime-tested.