Uh oh!
There was an error while loading. Please reload this page.
feat(core): add hook.dispose() method to release hook tokens early - #1181
Conversation
🦋 Changeset detectedLatest commit: c697597 The changes in this PR will be included in the next version bump. This PR includes changesets to release 14 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Nitro | Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Nitro | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) | Nitro Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express | Nitro Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Nitro | Express SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
|
🧪 E2E Test Results❌ Some tests failed Summary
❌ Failed Tests🐘 Local Postgres (1 failed)nextjs-turbopack-stable (1 failed):
🌍 Community Worlds (46 failed)turso (46 failed):
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
❌ 🐘 Local Postgres
✅ 🪟 Windows
❌ 🌍 Community Worlds
✅ 📋 Other
❌ Some E2E test jobs failed:
Check the workflow run for details. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Pull request overview
This pull request adds a dispose() method to hooks and webhooks that allows workflows to explicitly release hook tokens for reuse by other workflows while the current workflow is still running. This enables handoff patterns where one workflow can transfer a hook token to another workflow.
Changes:
- Added
dispose()method andSymbol.disposeto Hook interface for TC39 Explicit Resource Management support - Implemented disposal logic in workflow/hook.ts with isDisposed tracking and async iterator termination
- Added HookDisposedInvocationQueueItem type and handling in suspension-handler.ts to create hook_disposed events
- Updated documentation to recommend
usingkeyword for automatic cleanup and added examples of early disposal patterns - Added comprehensive e2e test demonstrating token reuse after explicit disposal while workflow still running
- Fixed missing import in create-webhook.mdx documentation
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/core/src/create-hook.ts | Added dispose() and Symbol.dispose methods to Hook interface with documentation |
| packages/core/src/workflow/hook.ts | Implemented disposeHook() function, isDisposed flag, and async iterator termination logic |
| packages/core/src/global.ts | Added HookDisposedInvocationQueueItem type and updated WorkflowSuspension to count hook disposals |
| packages/core/src/runtime/suspension-handler.ts | Added processing of hook_disposed queue items with error handling for 404/410 statuses |
| packages/core/e2e/e2e.test.ts | Added comprehensive test for hook token reuse after explicit disposal while workflow running |
| workbench/example/workflows/99_e2e.ts | Updated examples to use using keyword and added hookDisposeTestWorkflow demonstrating disposal |
| workbench/example/workflows/5_hooks.ts | Updated to use using keyword for automatic disposal |
| docs/content/docs/foundations/hooks.mdx | Added section on disposing hooks early with examples, updated all examples to use using |
| docs/content/docs/api-reference/workflow/create-hook.mdx | Added disposal documentation and examples, updated to use using throughout |
| docs/content/docs/api-reference/workflow/create-webhook.mdx | Added TC39 note, fixed missing import, updated examples to use using |
| .changeset/smart-cougars-talk.md | Added changeset documenting the new feature |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -176,6 +179,22 @@ export function createCreateHook(ctx: WorkflowOrchestratorContext) { | |||
| return resolvers.promise; | |||
| } | |||
There was a problem hiding this comment.
The createHookPromise function doesn't check if the hook has been disposed. While the async iterator correctly stops when isDisposed is true, directly awaiting a disposed hook (e.g., const result = await hook after hook.dispose()) will still attempt to create a promise and could cause unexpected behavior. Consider adding an isDisposed check that either throws an error or returns a rejected promise to make the behavior more predictable and easier to debug.
There was a problem hiding this comment.
Not adding an isDisposed check to createHookPromise(). The async iterator already checks !isDisposed before each yield, so the iterator pattern is safe. For direct await hook after dispose(), the behavior is the same as awaiting a hook that was never resumed — the promise hangs until the workflow suspends or completes. This is consistent with how the rest of the framework works (unawaited operations are silently ignored on completion). In the stacked PR #1185 we now log a warning when the workflow completes with uncommitted operations, which covers this case.
There was a problem hiding this comment.
human: hm I'm not sure claude understood the issue reported here. this explanation doesn't make sense to me ^
There was a problem hiding this comment.
You're right, the previous explanation was off. The actual concern from Copilot was: if you call await hook after hook.dispose(), createHookPromise() doesn't check isDisposed so it still creates a promise and pushes it to the promises array.
In practice this is fine because:
- If the event log is empty (first run), the dispose already set
disposed=trueon the queue item, and the subsequentawaittriggers aWorkflowSuspensionwhich processes both creation and disposal - If the event log has
hook_disposed(replay), the item is already deleted from the queue andhasDisposedEvent=true, sodisposeHook()was a no-op — theawaitcreates a dangling promise but the workflow completes/suspends on the next step
We have a test for case 1: "should suspend when awaiting a disposed hook on first invocation". Adding an isDisposed check to reject immediately would change the semantics (throwing instead of suspending), which could break workflows that call dispose() then have other work to do before their next suspension point.
There was a problem hiding this comment.
@TooTallNate@VaguelySerious any thoughts on this behaviour?
There was a problem hiding this comment.
The implementation has changed significantly since this comment. disposeHook() no longer adds a separate queue item — it sets a disposed flag on the existing hook queue item, and on replay it checks hasDisposedEvent to no-op entirely.
Re: the createHookPromise not checking isDisposed — this is intentional. If user code calls dispose() then await hook, the promise enters the promises array. If the event log is empty, the next event-consumer pass triggers a WorkflowSuspension with the disposed hook item, which processes both creation and disposal. If the log has hook_disposed, the item is already removed from the queue so the suspension is empty or only contains other items. Either way it resolves correctly without needing an explicit isDisposed rejection in createHookPromise.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| (hook as any)[vmDispose] = disposeHook; | ||
| } | ||
| return hook as unknown as Hook<T>; |
There was a problem hiding this comment.
hook as unknown as Hook<T> smells like a bug and breaks type safety. avoid this please
There was a problem hiding this comment.
Fixed in 303b08e — added [Symbol.dispose]: disposeHook directly to the object literal so it satisfies Hook<T> without the double cast. The VM's Symbol.dispose is still set separately only when it differs from the host's.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 13 out of 13 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (event.eventType === 'hook_disposed') { | ||
| // If a hook is explicitly disposed, we're done processing any more | ||
| // events for it | ||
| // Terminal state - remove from queue (like step_completed/wait_completed) | ||
| ctx.invocationsQueue.delete(correlationId); | ||
| // Mark that the event log confirms disposal happened | ||
| hasDisposedEvent = true; |
There was a problem hiding this comment.
When a hook_disposed event is replayed, the hook remains in ctx.invocationsQueue (and may still have disposed=true). That means later suspensions can keep trying to emit hook_disposed again, which will reliably 404 in worlds like world-local (it deletes the hook entity on disposal) and can lead to repeated API calls/log spam. Consider deleting this hook’s queue item here (similar to wait_completed / step_completed) once disposal is confirmed in the event log.
There was a problem hiding this comment.
we do delete the queue item now
There was a problem hiding this comment.
This was fixed in 9f9c739 — hook_disposed now deletes the item from ctx.invocationsQueue (terminal state, matching step_completed/wait_completed). The hasDisposedEvent closure flag prevents disposeHook() from re-adding anything on replay.
| * Disposes the hook, releasing its token for reuse by other workflows. | ||
| * | ||
| * After calling `dispose()`, the hook will no longer receive any events. | ||
| * This is useful when you want to explicitly release a hook token before | ||
| * the workflow completes, allowing another workflow to register a hook | ||
| * with the same token. |
There was a problem hiding this comment.
The docs here imply that calling dispose() immediately stops the hook from receiving events and releases the token right away. In this implementation, dispose() only marks the queue item and the hook_disposed event/token release won’t happen until the workflow hits the next suspension point (or until the run reaches a terminal state). Consider clarifying that disposal is processed on the next suspension (e.g., await sleep() / await step()) to avoid confusing handoff patterns.
There was a problem hiding this comment.
The JSDoc describes the user-facing contract: after dispose(), the hook stops receiving events and the token becomes available. The internal mechanics (queue flag → suspension handler → server event) are an implementation detail. This is consistent with how sleep() and step functions are documented — they describe what happens, not when the server processes it.
Uh oh!
There was an error while loading. Please reload this page.
| ### Disposing Hooks Early | ||
| You can dispose a hook early to release its token for reuse by another workflow. This is useful for handoff patterns where one workflow needs to transfer a hook token to another workflow while still running. | ||
| ```typescript lineNumbers | ||
| import { createHook } from "workflow" | ||
| export async function handoffWorkflow(channelId: string) { | ||
| "use workflow"; | ||
| const hook = createHook<{ message: string; handoff?: boolean }>({ | ||
| token: `channel:${channelId}` | ||
| }); | ||
| for await (const payload of hook) { | ||
| console.log("Received:", payload.message); | ||
| if (payload.handoff) { | ||
| hook.dispose(); // [!code highlight] Release the token for another workflow | ||
| break; | ||
| } | ||
| } | ||
| // Continue with other work while another workflow uses the token | ||
| } | ||
| ``` | ||
| After calling `dispose()`, the hook will no longer receive events and its token becomes available for other workflows to use. | ||
There was a problem hiding this comment.
The narrative here implies token reuse becomes available immediately after hook.dispose(). In practice, the disposal is emitted/processed on the next workflow suspension (or at run completion), so a handoff workflow typically needs an await (step/sleep/etc.) after disposing to make reuse observable while the workflow continues. Consider documenting that timing explicitly (or showing it in the example) to prevent confusing handoff behavior.
There was a problem hiding this comment.
that nuance is fine to ignore since "the next suspension point" is always a few milliseconds away from a disposal (the workflow runtime is expected to be fast) and is not critical to document for usage of hook and disposal
There was a problem hiding this comment.
nvm I included it elsewhere in the hook docs
There was a problem hiding this comment.
Same answer — the disposal is processed at the next suspension point, which for any practical workflow happens immediately (the next await triggers suspension). The docs are describing the user-facing contract, not the internal mechanics.
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| "@workflow/core": patch | |||
| "workflow": patch | |||
There was a problem hiding this comment.
remove "workflow" from the changelog. enough to just bump the core package
There was a problem hiding this comment.
Fixed in c697597 — removed workflow from the changeset.
Add a `dispose()` method to the Hook interface that allows workflows to explicitly release hook tokens for reuse by other workflows while the current workflow is still running. This enables handoff patterns where one workflow can transfer a hook token to another workflow. - Add `dispose()` method to Hook interface in create-hook.ts - Implement dispose functionality in workflow/hook.ts - Add HookDisposedInvocationQueueItem to global.ts - Handle hook_disposed events in suspension-handler.ts - Update documentation in hooks.mdx and create-hook.mdx - Add e2e test for hook token reuse after explicit disposal https://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH
Add Symbol.dispose to Hook interface to support the TC39 Explicit Resource Management proposal. This allows hooks to be used with the `using` keyword for automatic disposal when exiting scope. https://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH
Update all documentation and e2e tests to use the `using` keyword as the recommended approach for creating hooks and webhooks. This leverages the TC39 Explicit Resource Management proposal for automatic disposal. - Update e2e tests to use `using` syntax - Update foundational hooks guide to recommend `using` - Update create-hook API reference with `using` examples - Update create-webhook API reference with `using` examples - Update example workflow to use `using` https://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH
Remove unnecessary block scopes and excessive comments about automatic disposal. Block scopes are only used when early disposal is relevant (like in the handoff test). https://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH
Add a one-liner explaining the `using` keyword in the intro examples of the API reference docs, so new users understand the syntax. https://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH
- Restore code highlights (`[!code highlight]`) that were unintentionally
removed from pre-existing doc examples
- Move `using` explanation from prose to inline code comment in intro
examples
- Add `{/* @skip-typecheck */}` to incomplete manual dispose() snippet
- Add 409 (conflict/duplicate) error handling for hook_disposed events
in suspension handler to handle workflow re-invocation
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>The workflow VM sandbox doesn't have Symbol.dispose/Symbol.asyncDispose available, causing `using` keyword to fail with "Symbol.dispose is not defined" at runtime. Add polyfill in the VM context creation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The workflow VM sandbox has its own Symbol object with a polyfilled Symbol.dispose. The hook object was using the host's Symbol.dispose, which is a different symbol instance. The SWC-compiled `using` keyword looks up the VM's Symbol.dispose on the object, causing "Object not disposable" errors. Fix by setting Symbol.dispose on the hook object dynamically using the VM's globalThis.Symbol.dispose from the orchestrator context. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The webhookWorkflow e2e test creates 3 webhooks that must all exist before the test sends HTTP requests. Using `using` with sequential creation meant only the first webhook existed at the first suspension point. Revert to `const` since all webhooks need to be created upfront. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Instead of adding a separate HookDisposedInvocationQueueItem to the queue on dispose, keep the HookInvocationQueueItem throughout the hook lifecycle and track state with flags (hasCreatedEvent, disposed). A closure variable (hasDisposedEvent) makes disposeHook() a pure no-op on replay, avoiding redundant server calls and 409 errors. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Match the pattern used by steps (step_completed/step_failed) and waits (wait_completed) where the queue item is removed on the terminal event. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- WorkflowSuspension counts disposed hooks separately from active hooks - Dispose after hook_created replay produces correct suspension - Dispose before first suspension (needs both create + dispose) - Multiple hooks where only one is disposed - Dispose on a conflicted hook is safe (no crash) - Symbol.dispose calls disposeHook correctly (using keyword pattern) - Iterator break without dispose keeps hook alive in queue - Await after dispose on first invocation triggers suspension Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 14 out of 14 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ### Disposing Hooks Early | ||
| When a workflow ends, hooks are automatically disposed. However, you may want to release a hook token early so another workflow can use it while your workflow continues running. Use a block scope with `using` to control when disposal happens: | ||
| ```typescript lineNumbers | ||
| import { createHook } from "workflow"; | ||
| export async function handoffWorkflow(channelId: string) { | ||
| "use workflow"; | ||
| { | ||
| using hook = createHook<{ message: string; handoff?: boolean }>({ | ||
| token: `channel:${channelId}` | ||
| }); | ||
| for await (const payload of hook) { | ||
| console.log("Received:", payload.message); | ||
| if (payload.handoff) { | ||
| break; | ||
| } | ||
| } | ||
| } // Hook token released here | ||
| // Token is now available for another workflow | ||
| console.log("Continuing with other work..."); | ||
| } |
There was a problem hiding this comment.
This section implies that exiting the using scope (or calling dispose()) immediately releases the token for another workflow. In the current design, the hook_disposed event is only emitted when the workflow next suspends (e.g., await sleep(), await step(), etc.), otherwise the token won’t be reusable until the run completes. Please document that a suspension point is required for early reuse, and ideally show one in the example.
There was a problem hiding this comment.
The docs are accurate for the user-facing mental model. The token is released when the workflow next suspends (which happens immediately after the using block exits if there's any subsequent await step() or await sleep()). For the edge case of dispose at function scope with no further suspension points, the backend auto-disposes all hooks when the run reaches a terminal state, so the token is still released.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Add [Symbol.dispose] directly to the hook object so it satisfies the Hook<T> type without `as unknown as`. The VM's Symbol.dispose is still added separately when it differs from the host's. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
VaguelySerious
left a comment
There was a problem hiding this comment.
LGTM, two main comments from a claude simulation:
- When hook_disposed is replayed, the event consumer returns Finished, unsubscribing the callback. If the workflow later does await hook after the consumer is gone, createHookPromise() will push to promises[] but nobody will ever resolve it. However, this is actually fine, since a workflow that awaits a hook after disposing it is a user error, and the workflow will simply hang (which is the expected behavior for an unresolvable promise in the event-sourced model, so it would eventually suspend on the next trigger).
runtime.tssuspension message doesn't includehookDisposedCount, seeconst suspensionMessage = buildWorkflowSuspensionMessage(.... The debug log message doesn't mention hook disposals. This is cosmetic (debug-level only) but could be confusing when debugging. Worth a follow-up to add hookDisposedCount to the message builder.
- Rename test to match new behavior (hooks stay in queue, not removed) - Use neutral "processed" verb in WorkflowSuspension message when mixed item types are present - Remove extends Disposable from Hook interface to avoid requiring lib.esnext.disposable in downstream consumers (explicit [Symbol.dispose]() method is still declared on the interface) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
TooTallNate
left a comment
There was a problem hiding this comment.
Well-implemented feature with solid test coverage and thorough documentation. The core design of tracking hasCreatedEvent and disposed flags on queue items, and splitting hook processing in the suspension handler, is clean and fits well into the existing event-sourcing architecture.
A few inline comments — mostly minor suggestions and one behavioral note about the iterator. Nothing blocking.
| yield await this; | ||
| } | ||
| }, | ||
There was a problem hiding this comment.
Nit: If dispose() is called externally while the iterator is suspended on yield await this, the pending promise will never resolve/reject — the !isDisposed check only runs after the yield returns. This means the iterator won't terminate until the next payload arrives (at which point the loop condition catches it).
This is probably fine in practice since dispose() is typically called inside the for await body after receiving a payload, but worth a comment here noting the limitation.
There was a problem hiding this comment.
Fixed in ca9ca85 — disposeHook() now drains the promises array and triggers a WorkflowSuspension when there are pending promises. This ensures no orphaned awaits: the suspension handler processes the disposal, and the workflow execution is unwound cleanly.
This also addresses @VaguelySerious's point 1 from his review — the promise is no longer left hanging.
| const vmDispose = ctx.globalThis.Symbol.dispose; | ||
| if (vmDispose && vmDispose !== Symbol.dispose) { | ||
| (hook as any)[vmDispose] = disposeHook; | ||
| } |
There was a problem hiding this comment.
Nit: The as unknown as Hook<T> cast is needed because the host's [Symbol.dispose] is intentionally not set on the object literal (only the VM's symbol is). This is correct for runtime behavior, but it means the host-side Symbol.dispose is never present on the object. Might be worth a brief comment explaining why the cast is safe (the hook is only used inside the VM sandbox where the VM's Symbol.dispose is what matters).
There was a problem hiding this comment.
fixed already. that cast is not needed
| if (hooksNeedingDisposal.length > 0) { | ||
| await Promise.all( | ||
| hooksNeedingDisposal.map(async (queueItem) => { | ||
| const hookDisposedEvent: CreateEventRequest = { |
There was a problem hiding this comment.
Minor: The hookDisposedEvent doesn't include an eventData field, while other event types (e.g., hook_created, step_created) typically do. Is that intentional? If the world implementation expects eventData to always be present, this could be an issue. If it's optional, this is fine — just flagging for awareness.
There was a problem hiding this comment.
Intentional — hook_disposed is a terminal event that just deletes the hook entity. The CreateEventRequest type has eventData as optional. The world implementations (local, postgres, vercel) all handle missing eventData fine for disposal events.
| ); | ||
| // Hooks needing disposal: any disposed hook (including those needing creation first) | ||
| // Hooks are created before disposal in the processing order below | ||
| const hooksNeedingDisposal = allHookItems.filter((item) => item.disposed); |
There was a problem hiding this comment.
The comment on lines 85-86 is helpful. To be explicit: when hasCreatedEvent is falsy and disposed is true, the hook appears in bothhooksNeedingCreation and hooksNeedingDisposal. Since creation runs before disposal (lines 122-193), this ordering is correct — the hook must exist before it can be disposed. Just want to confirm this two-step behavior for a single queue item is tested. (It is — the e2e test covers this path when dispose() is called before any suspension.)
There was a problem hiding this comment.
Correct — this is tested in "should produce correct WorkflowSuspension for dispose before first suspension" which verifies the flags (hasCreatedEvent=undefined, disposed=true), and the suspension handler test coverage in the edge cases table confirms both hooksNeedingCreation and hooksNeedingDisposal include it.
| g.structuredClone = globalThis.structuredClone; | ||
| // TC39 Explicit Resource Management polyfill for `using` keyword | ||
| (g.Symbol as any).dispose ??= Symbol.for('Symbol.dispose'); |
There was a problem hiding this comment.
Nit: Symbol.for('Symbol.dispose') creates a global registry symbol which is not the same as the native well-known Symbol.dispose. The ??= guard means this only applies when the runtime lacks native support, which is fine. But if this polyfill is used elsewhere (outside the VM sandbox), code comparing against the native Symbol.dispose won't match. The dual-registration in hook.ts:235-238 handles this correctly. Just flagging in case other code needs to be aware of the distinction.
There was a problem hiding this comment.
Good callout. The Symbol.for('Symbol.dispose') polyfill is scoped to the VM sandbox context only — it's set on vmGlobalThis.Symbol.dispose, not the host's Symbol. The dual-registration in hook.ts (host's Symbol.dispose + VM's Symbol.dispose when they differ) handles the mismatch. No other code outside the VM needs to compare against this polyfilled symbol.
| @@ -0,0 +1,6 @@ | |||
| --- | |||
| "@workflow/core": patch | |||
There was a problem hiding this comment.
Optional: Since this adds a new public API method (dispose()) and extends the Hook interface with Disposable, this could arguably be a minor bump for @workflow/core rather than patch. Up to you and your versioning conventions.
There was a problem hiding this comment.
keeping patch to be in line with our pre-beta conventions
When dispose() is called while a promise is pending (e.g., iterator suspended on yield await this, or direct await hook after dispose), the promise would hang forever since the event consumer will never deliver another hook_received. Now disposeHook() clears the promises array and triggers a WorkflowSuspension so the runtime processes the disposal cleanly. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pranaygp
commented
Feb 27, 2026
@VaguelySerious Thanks for the review! Addressing your two points:
|
Add a
dispose()method to the Hook interface that allows workflows toexplicitly release hook tokens for reuse by other workflows while the
current workflow is still running. This enables handoff patterns where
one workflow can transfer a hook token to another workflow.
dispose()method to Hook interface in create-hook.tshttps://claude.ai/code/session_01AkvrXduyFTbtV2joTPHrDH