Does resuming a workflow hook use the same version?

main
05ecfbc[cli] Ensure npm pre-release versioning works for post-GA release pre-releases (#722)
This post might have stale content, as main is 12 commits ahead.

if i start a workflow and start a hook inside of it, then i resume it some time after: will it hit the same workflow version at all times? even if i deploy a new version of it? i mean it'll be the same workflow, just a different hook resume call. not sure.

Avatar of Claude Haiku 4.5Claude Haiku 4.5commented

I'll help you understand how workflow versioning works when resuming from hooks. Let me explore the codebase to find the relevant implementation.

Let me look at the core workflow resumption logic to understand how versioning works:

Now let me check the start function to understand how workflows are invoked and whether versioning is involved:

Now let me check how the workflow queue actually executes the workflow code:

Let me check how the workflow code is retrieved and executed:

Let me look for where the queue message is processed and how the workflow code is executed:

Let me look at how the workflow is queued and then executed, starting with understanding the queue handler setup:

Let me look at the core runtime where the workflow queue handler is set up:

Perfect! Now I can see the key piece. Let me continue reading:

Perfect! Now I have the full picture. Let me check what happens when the hook is resumed - does it use the same workflowCode:

Perfect! Now I have all the information I need. Let me provide you with a comprehensive answer.

##Answer

Yes, when you resume a workflow from a hook, it will always use the same workflow version that was originally deployed when the workflow was first started — even if you've deployed a new version of the workflow code since then.

Here's how it works:

###Key Implementation Details:

  1. Initial Workflow Invocation (when you call start(workflow, args)):

    • The workflow is queued with a specific deploymentId
    • The queue message stores the runId and references this deployment
  2. Hook Registration (when you createHook() inside the workflow):

    • The hook is created and associated with that workflow run
    • The hook stores a reference to the original workflowRun.deploymentId
  3. Hook Resumption (when you call resumeHook(token, payload)):

    await world.queue(
      `__wkf_workflow_${workflowRun.workflowName}`,
      { runId: hook.runId, traceCarrier: ... },
      {
        deploymentId: workflowRun.deploymentId,  // ← Uses original deployment!
      }
    );
    

    It re-queues the workflow using the same deploymentId from the original run, not the current/latest deployment.

  4. Workflow Execution:

    • When the queue handler processes the message, it uses the workflowCode that's bound to that specific deployment
    • The workflow replays from its event log with the exact same code version that originally created the hook

###Why This Matters:

This design ensures deterministic execution. If the workflow code had changed between the initial invocation and the hook resumption, the replay could diverge from the original execution path, potentially causing inconsistencies. By always using the original deployment's code, the workflow maintains a consistent, reproducible execution path.


END OF POST

Log in to add a comment
Claude Haiku 4.5
Does resuming a workflow hook use the same version? — vercel/workflow