fix(worker): expose workflow variables in HTTP step conditions fixes NV-8772

[nikitagrossman]

What changed

HTTP Request steps now evaluate dashboard skip conditions against the same workflow namespace as every other step type. workflow.workflowId also starts resolving on the Framework path.

Why

HTTP Request is the only step type that evaluates controlValues.skip locally in the worker. Its compile context omitted workflow, so conditions like workflow.name equals Pawan compared against undefined and the activity feed showed evaluatedValues: {}.

Channel, digest, delay, and throttle steps already get workflow from ConstructFrameworkWorkflow, but that object is the raw Mongo entity and has no workflowId field — the dashboard picker advertises workflow.workflowId as the trigger identifier.

How

• Shared buildWorkflowVariables() spreads the workflow entity and maps triggers[0].identifier → workflowId.
• HTTP step resolves the workflow once, then uses it for control-value lookup and skip/Liquid compile context.
• Framework fullPayloadForRender.workflow goes through the same helper.

flowchart TD
  Cond["Dashboard skip condition"] --> Type{"Step type"}
  Type -->|"email, in-app, sms, chat, push, throttle"| Bridge["SendMessage to bridge"]
  Type -->|"digest, delay"| AddJob["AddJob to bridge"]
  Type -->|"http_request"| Local["ExecuteHttpRequestStep evaluateRules"]
  Bridge --> Helper["buildWorkflowVariables"]
  AddJob --> Helper
  Local --> Helper
  Helper --> Ctx["workflow.name, workflow.workflowId, ..."]

Loading

Test plan

• HTTP step skip on matching / non-matching workflow.name
• HTTP step skip on workflow.workflowId (trigger identifier)
• Activity evaluatedValues is populated instead of {}
• {{ workflow.name }} compiles in the HTTP request body
• Framework skip on workflow.workflowId for channel steps
• buildWorkflowVariables unit spec

Out of scope

• Legacy v0 step.filters evaluated by ConditionsFilter still have no workflow namespace.
• Digest/delay re-evaluate dashboard skip only at scheduling time (AddJob), not after the wait window.

Fixes NV-8772

Made with Cursor

Confidence Score: 5/5

The PR appears safe to merge.

What we checked:

• Private workflow fields stay hidden: No. buildWorkflowVariables returns only the five dashboard fields, and the HTTP step uses that result as its workflow value.

Summary

HTTP Request steps now expose the same filtered workflow variables as other step types when checking skip rules and rendering request bodies. A shared helper maps the first trigger identifier to workflow.workflowId, so both worker and Framework paths use the same workflow namespace. Major changes: HTTP steps resolve workflow data before evaluating conditions; Framework steps use the shared workflow payload; tests cover names, IDs, evaluated values, and Liquid rendering.

Diagram

sequenceDiagram
    participant Job as HTTP step job
    participant Worker as ExecuteHttpRequestStep
    participant Repo as Workflow repository
    participant Helper as buildWorkflowVariables
    participant Rules as Skip rules
    participant HTTP as HTTP endpoint

    Job->>Worker: execute(command)
    alt command includes workflow
        Worker->>Worker: use command.workflow
    else command has _templateId
        Worker->>Repo: findById(_templateId, environmentId)
        Repo-->>Worker: workflow
    end
    Worker->>Helper: buildWorkflowVariables(workflow)
    Helper-->>Worker: workflowId, name, description, tags, severity
    Worker->>Rules: evaluate skip with workflow context
    alt condition says skip
        Rules-->>Worker: skip
        Worker-->>Job: SKIPPED
    else condition says run
        Rules-->>Worker: run
        Worker->>HTTP: send compiled request
        HTTP-->>Worker: response
        Worker-->>Job: result
    end

Loading

_{Reviews (3) · Last reviewed commit: "Refactor schema typing and JSON parsing"}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
human-md	Ready	Preview	Sep 20, 2026 7:47am UTC

[netlify]

✅ Deploy Preview for dashboard-v2-novu-staging canceled.

Name	Link
🔨 Latest commit	9dd79f7
🔍 Latest deploy log	https://app.netlify.com/projects/dashboard-v2-novu-staging/deploys/6aaf8f9815c6550008735f90

[linear-code]

NV-8772

[cursor]

🔒 Agentic Security Review — 1 finding (HIGH)

Reviewed PR #12675: fix(worker): expose workflow variables in HTTP step conditions fixes NV-8772
Author: @nikitagrossman

Summary: The fix is correct — HTTP request steps now get the workflow namespace. However, buildWorkflowVariables spreads the entire NotificationTemplateEntity into the Liquid compile context rather than allowlisting only the five fields the dashboard variable picker advertises. For the HTTP step path this is entirely new exposure, and the spread pulls in sensitive sub-documents including the updatedBy populated UserEntity (with no field projection in findById), which contains password (bcrypt hash), resetToken (live account-takeover token), and tokens (OAuth access/refresh tokens).

  

_{Sent by Cursor Security Agent: Security Reviewer}