A workflow trigger should return the run it created
GitHub's dispatch response can identify the run a request created. Keep February's opt-in contract, concurrent callers and ambiguous retry failures clear.
By 
Paul. Architecture and infrastructure
An automation that triggers work should keep the identity of the work it created. Looking up the latest workflow run afterwards answers a different question: which run happens to be newest when the lookup executes. Those answers can coincide in a quiet repository. Under concurrent use, their difference becomes a correctness problem. Returning the created run's identity gives the caller a direct correlation contract.
GitHub's 19 February 2026 announcement introduced an opt-in response for workflow dispatch. This is a retrospective of the week beginning 18 February. Its subject is the February contract, rather than a claim that every API version or client available in November exposes identical behavior. That distinction matters when existing integrations expect an empty response.
The newest run can belong to someone else
Imagine two hypothetical callers dispatching the same workflow against the same branch. One asks for a release candidate; another asks for a separate validation. Both requests can occur before either caller lists the runs. Selecting the latest result does not establish which request produced it. Matching the workflow name and branch narrows the candidates, but those properties can legitimately be shared.
A delay does not repair that missing relationship. Waiting longer might make a run visible, while also allowing more unrelated runs to appear. Adding a short sleep therefore changes timing without proving identity. The useful question is whether the response names the run created by this request. If it does, the caller can persist that identity before beginning later observation.
This is an interpretation of the interface's value, not a report of a locally observed race or a measured polling improvement. The benefit concerns the meaning of the association. An integration should not need the repository to stay quiet in order to know which run it is following.
Keep the opt-in boundary explicit
The February changelog described an optional boolean, return_run_details. Opting in returned 200 OK with identifying metadata; omitting the parameter preserved 204 No Content. It also identified GitHub CLI v2.87.0 as supporting the change through gh workflow run. The separate CLI release record belongs to the version history; the changelog supplies the dated statement about support.
That compatibility boundary is useful. A caller that checks specifically for 204 can reject a successful 200 response if its implementation has not been updated. A migration should decide when to opt in, how to validate the returned identity and where to store it. Broadly accepting any success status while still discarding the response would miss the feature's purpose.
The current workflow documentation illustrates response fields named workflow_run_id, run_url and html_url. These distinguish the run identifier, its API address and its browser address. It is moving documentation, and its current dispatch section shows a 200 response without reproducing February's optional-parameter description. Use the dated changelog for the historical opt-in claim; do not project today's documentation backwards as an unchanged February schema.
Store identity before reporting progress
Once a caller has a run identity, later status handling should continue to use it. Replacing it with another latest-run search during error recovery would reintroduce the ambiguity. A job record can conceptually associate the caller's request with the returned run, allowing a person to inspect the same execution the automation follows. This is a design recommendation, not a claim about any particular storage implementation.
Identity also helps separate dispatch from completion. Receiving a run identifier does not mean the workflow has succeeded. A caller may still need to observe queued, running or terminal behavior and decide which outcome is relevant to its own task. Its user-facing message should reflect what has actually been established. “Created” and “completed successfully” are different assertions.
A browser URL is useful for investigation, but it does not establish access for everyone who receives it. Repository visibility and the viewer's authorization remain relevant. Including the address in a notification should therefore be a deliberate part of the integration, especially where logs or messages can reach a wider audience than the repository itself.
A run ID does not make retries idempotent
The strongest limitation appears when the dispatch request succeeds at the server but the response never reaches the caller. The server may have created a run while the caller has no identity to store. Retrying can create another run. Returning an identifier on successful responses does not, by itself, promise that repeated requests are collapsed into one execution.
That ambiguous failure needs its own policy. Depending on the consequences of the workflow, an integration might pause for reconciliation or use a separately designed deduplication mechanism. It must not assume such a mechanism exists because the API returns an ID. An identifier describes an execution; idempotency describes the effect of repeating an operation. Conflating them hides the remaining risk.
The same distinction applies to a person pressing a trigger twice. Two valid requests can still represent unwanted duplicate work. The receiving workflow's handling of repeated business operations remains a separate design question. The February change improves correlation without settling that question for the application.
In custom software development, make both contracts reviewable: how a request becomes associated with a run, and what happens when the request's outcome is unknown. GitHub's change removes a fragile inference from the ordinary success path. The integration still needs an honest response to the moment when no response arrives.