A second notebook-cell invocation or a late response must not automatically deliver the same action again. Within one active SDK execution, the host retains the promise it already started. I describe that protection by its actual lifetime, rather than calling it permanent duplicate prevention or exactly-once behavior on every external service.
Validate the current run connection before considering reuse
An SDK request carries run identity, access credentials, method, key and inputs. The host compares credentials and identity, requires the same active object and rejects a closed execution. This is not a global cache that returns historical output because a workflow name happens to match.
Run credentials do not belong in reusable source or ordinary result records. Finishing or stopping closes that connection lifetime. Sending the same key through a new run does not locate the former promise in a global lookup. Connection validation and reuse are deliberately bound to the same active execution.
Retain both the first key and its input fingerprint
The first request retains its key and input fingerprint. Later requests with a different key or fingerprint are rejected. Equal keys cannot disguise changed content, and equal content under another key is not guessed to be the same request either.
This path hashes the JSON serialization of the input mapping without a separate key-sort normalization. A mapping constructed in a different key order can therefore compare differently despite equivalent values. The implementation is not a semantic-equivalence detector for every possible input representation. Keeping a consistent request representation remains part of the caller contract.
Await the existing promise instead of creating the actions again
The host creates repeat and recipe execution only when the active promise is absent. Otherwise it awaits that same promise and returns the retained result. A second request arriving before completion follows the existing progress instead of beginning another operation. Response latency is not evidence that work never started.
A failed promise is not replaced by a new success attempt within this lifetime. Reading a result and redelivering an action are separate operations. An input already delivered to a service can remain there after a local response disappears. Transport retry must not quietly become business replay behind the same convenient function name.
An active-run gate differs from a durable item journal
The active key and promise live in memory; they are not restored as an unconditional continuation after application restart. The historical-status path treats a retained running record as review-needed. Starting another identity without reconciling the original external result creates a new request outside this active-run protection.
The operations notebook journal handles job and item continuation at another layer. Similar names do not justify combining their guarantees. One binds re-entry while an execution is alive; the other retains item records across executions. Designing reuse begins with identifying which lifetime the workflow actually needs.
Separate the inspected code boundary from execution evidence
This article directly reads the SDK request shape, active-run checks, input comparison and retained promise. It does not send new duplicate SDK calls through the original browser. Existing operations-notebook tests separately check that revisiting a completed item does not increase execution count.
Those tests concern the journal layer, not fresh verification of every connection failure in this route. The shared waiting module also illustrates reading an existing run; it is not a clone of the SDK promise gate. Related protections still need their own identified evidence instead of borrowing confidence from a nearby test.
A late answer is not a reason to start another operation
When progress looks quiet, people naturally press again. A useful interface should offer the existing run identity and status before another button that creates work. Reuse is therefore more than a hidden optimization: it supports an explanation of what the user is waiting for.
Approvals and submissions in business software share that concern. A delayed response and an operation that never ran are different conditions. Receiving an existing result again must remain distinct from beginning a new occurrence of the work. Retaining one promise makes that distinction concrete inside the execution code.