Await or Subscription¶
Synchronization interface — instantiates Deferred Fulfillment Placeholder
Lets a consumer watch a placeholder's public state and receive streamed updates until it resolves, without pretending the value is already in hand.
Await or Subscription is the consumer-facing observation interface on a deferred placeholder: the way a party that wants the eventual value parks itself against the placeholder and is pushed what it needs to know as the placeholder progresses and finally resolves. Its defining move is that the consumer keeps its own control flow — it either blocks on the placeholder ("await") or holds a live subscription channel — and the placeholder does the informing. It reads the placeholder's public state label and receives a stream of progress updates; it does not hand over a function to be run for it, and it does not repeatedly interrogate a status field on its own schedule. In short: the consumer watches and is notified. That "pushed to me while I hold a live view" quality is exactly what separates it from its two nearest siblings.
Example¶
A customer buys a couch online and is offered "track this delivery." Choosing it opens a subscription to the shipment's pending-delivery placeholder. From then on, the customer's app doesn't have to keep asking — the carrier pushes updates over the live channel: label: In transit, then a progress signal as the truck moves through the route ("14 stops away… 3 stops away"), then a narrowing delivery window. The visible label the customer reads is always the placeholder's own public state, not a guess the app invented, so what they see and what the carrier believes never drift apart.
When the driver marks the package delivered, the placeholder resolves and the subscription delivers a final push: label: Delivered. The customer never once refreshed a page or polled a tracking number by hand; they held an open view and were told. Had they instead wanted the app to do something on delivery — say, unlock a smart lock — that would be a different mechanism (a registered continuation), not this one. Await/Subscription's job ended at "you now know."
How it works¶
- Attach to the placeholder's public view. The consumer binds to the placeholder's externally visible state label — the sanctioned representation of pending/progressing/resolved — rather than to internal producer state.
- Choose block or subscribe. Await suspends the consumer's own flow until resolution and then yields the value or terminal outcome. Subscribe keeps the consumer running while a live channel pushes updates. Both are pull-my-attention-in / get-pushed models, not run-this-for-me models.
- Receive progress, then finality. Between attach and resolution, the interface relays whatever progress signal the placeholder emits; at resolution it delivers the terminal transition once.
- Detach. On resolution (or on the consumer losing interest) the subscription is released, so a resolved placeholder isn't holding live watchers forever.
The interface neither resolves the placeholder nor decides who may — it only surfaces state that already exists.
Tuning parameters¶
- Block vs. stream — a one-shot blocking await versus a long-lived subscription. Blocking is simplest when the consumer has nothing else to do; streaming suits UIs and dashboards that must stay live.
- Progress granularity — coarse (
pending→done) or fine (percent complete, stage labels, ETAs). Finer progress is more reassuring and more actionable but costs more to emit and can leak internal detail. - Delivery semantics — at-most-once, at-least-once, or exactly-once notification, and whether a late subscriber gets replayed history or only future updates. Replay lets someone who attaches late catch up; forward-only is lighter.
- Fan-out — how many concurrent watchers one placeholder supports, and whether they share a single broadcast or each get an isolated stream.
- Label freshness — how tightly the visible label tracks true state. Tighter is more honest; looser reduces chatter but risks showing stale status.
When it helps, and when it misleads¶
Its strength is that it lets a consumer coordinate around a future value without owning any waiting logic — the publish–subscribe posture[n1] means the placeholder pushes truth to watchers instead of watchers guessing. It also keeps everyone consistent: multiple subscribers see the same authoritative label and resolution, avoiding the archetype's "different representations of the same future result" failure.
Its failure mode is the silent stall: a subscription that simply stops receiving because the producer died or the channel dropped looks identical, to the watcher, to a placeholder that is merely still working. Absence of a push is not evidence of continued pending. A classic misuse is trusting a "live" tracker that has actually gone stale, so a customer waits calmly for a truck that was cancelled hours ago. The guarding discipline is to pair the stream with liveness — heartbeats or a visible "last updated" — and to lean on a deadline mechanism (Timeout Expiration Handler) so a placeholder that goes quiet is eventually forced to a terminal state rather than watched forever.
How it implements the components¶
Await or Subscription fills the observation components — the consumer's read-and-be-notified surface:
progress_signal— relays the placeholder's in-flight progress to the watching consumer as it advances toward resolution.promise_visibility_label— binds the consumer to the placeholder's sanctioned public state label, so what they observe is the placeholder's own truth.
It does not implement dependent_continuation_set or fallback_value_or_path — registering work to run on resolution is the push twin, Callback or Continuation Registration. Nor does it implement pending_state_record: repeatedly interrogating that record on the consumer's own clock is Pending State Polling. Await/Subscription observes; it does not poll and it does not delegate.
Related¶
- Instantiates: Deferred Fulfillment Placeholder — this is the read-side interface for coordinating around a pending value.
- Consumes: Promise Creation Protocol — there must be a placeholder, with a public label, to subscribe to.
- Sibling mechanisms: Callback or Continuation Registration · Pending State Polling · Promise Creation Protocol · Resolution Event Commit · Cancellation Propagation · Failure Propagation · Dependency Graph Scheduling · Resolved Value Memoization · Timeout Expiration Handler
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: The mechanism defines a consumer-placeholder synchronization arrangement in which a consumer either suspends on public state or remains live while updates stream until resolution, so its operative form is an interaction architecture.
Nearest alternative: Interface, Display & Cue — The consumer observes a public interface, but this is an internal coordination topology between components rather than a user-facing perceptual surface.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Asynchronous programming developed futures, promises, await operations, and subscriptions for observing deferred values without pretending they are resolved.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
[n1] The publish–subscribe pattern decouples producers from consumers: subscribers register interest and are pushed updates rather than repeatedly asking. That push posture is precisely what distinguishes a subscription from a polling loop. ↩