-
Notifications
You must be signed in to change notification settings - Fork 3.2k
Description
Bug Description
When a block reference cannot be resolved in function/condition blocks, the variable substitution defaults to empty string ("") instead of undefined. This breaks the nullish coalescing operator (??) in user code.
Root Cause
In apps/sim/app/api/function/execute/route.ts, the resolveTagVariables function uses:
let tagValue = getNestedValue(params, tagName) || getNestedValue(blockData, tagName) || ''This defaults to empty string when a reference cannot be resolved. In user code that uses ??, the empty string is treated as a valid value (not nullish), preventing fallback logic from working:
// User code
const conversationId = webhook1ConvId ?? webhook1ConvIdField ?? webhook1Id ?? startConvId;When webhook1ConvId is substituted as "" (instead of undefined), the ?? never reaches startConvId.
Impact
- Function/condition blocks cannot reliably use nullish coalescing for fallback values
- Workflows that depend on
??for optional field handling will fail unexpectedly - Workaround forces users to use verbose truthy checks instead of modern JavaScript patterns
Example
Webhook trigger missing field:
const value = <webhook.optional_field> ?? 'default'; // Returns '' instead of 'default'Expected behavior: Returns 'default'
Actual behavior: Returns ''
Solution
Change the fallback to use undefined instead of empty string:
let tagValue = getNestedValue(params, tagName) ?? getNestedValue(blockData, tagName)Affected Code Locations
- Line 528: Initial substitution should not default to
'' - Line 542: Second fallback should not default to
''
Files to Update
apps/sim/app/api/function/execute/route.ts-resolveTagVariablesfunction
Testing
This should be verified with a workflow that:
- Has a webhook trigger with optional fields
- Uses
??to fall back to start trigger values - Confirms the fallback chain works correctly