fix(executor): skip Response block formatting for internal JWT callers#3551
fix(executor): skip Response block formatting for internal JWT callers#3551waleedlatif1 merged 3 commits intostagingfrom
Conversation
The workflow executor tool received `{error: true}` despite successful child
workflow execution when the child had a Response block. This happened because
`createHttpResponseFromBlock()` hijacked the response with raw user-defined
data, and the executor's `transformResponse` expected the standard
`{success, executionId, output, metadata}` wrapper.
Fix: skip Response block formatting when `authType === INTERNAL_JWT` since
Response blocks are designed for external API consumers, not internal
workflow-to-workflow calls. Also extract `AuthType` constants from magic
strings across all auth type comparisons in the codebase.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
PR SummaryMedium Risk Overview Introduces Written by Cursor Bugbot for commit abf0881. Configure here. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Greptile SummaryThis PR fixes a bug where child workflows containing a Response block would cause parent Agent block calls to misinterpret a successful execution as a failure. It also performs a codebase-wide cleanup replacing magic auth-type strings with a typed
Confidence Score: 5/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[POST /api/workflows/id/execute] --> B[checkHybridAuth]
B --> C{auth.authType?}
C -->|INTERNAL_JWT| D[executeWorkflowCore]
C -->|API_KEY| E[executeWorkflowCore]
C -->|SESSION| F[executeWorkflowCore]
C -->|Public API| G[executeWorkflowCore]
D --> H{workflowHasResponseBlock?}
E --> I{workflowHasResponseBlock?}
F --> J{workflowHasResponseBlock?}
G --> K{workflowHasResponseBlock?}
H -->|true| L[SKIP — return standard wrapper\nsuccess + executionId + output + metadata]
H -->|false| L
I -->|true| M[createHttpResponseFromBlock\nraw user-defined data]
I -->|false| N[return standard wrapper]
J -->|true| M
J -->|false| O[return standard wrapper]
K -->|true| M
K -->|false| P[return standard wrapper]
style L fill:#90EE90
style M fill:#FFD700
|
Verify that internal JWT callers receive standard format while external callers (API key, session) get Response block formatting. Tests the server-side condition directly using workflowHasResponseBlock and createHttpResponseFromBlock with AuthType constants. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Route code now imports AuthType from @/lib/auth/hybrid, so test mocks must export it too. Added AuthTypeMock to @sim/testing and included it in all 15 test files that mock the hybrid auth module. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
@greptile |
|
@cursor review |
Summary
createHttpResponseFromBlock()returns raw user-defined data (e.g.{issues: []}) instead of the standard{success, executionId, output, metadata}wrapper. The executor tool'stransformResponsedoesdata?.success ?? false, which evaluates tofalsefor Response block payloads → all LLM providers interpret this as failure.auth.authType === AuthType.INTERNAL_JWT— Response blocks are designed for external API consumers, not internal workflow-to-workflow calls. The auth type check is placed first for short-circuit efficiency (cheap string comparison before expensive log iteration).AuthTypeconstants (SESSION,API_KEY,INTERNAL_JWT) from magic strings across all auth type comparisons in the codebase (11 files).Test plan
bunx vitest run tools/workflow/executor.test.ts)bunx tsc --noEmit)