fix(journey): fall back to session journeyId so journey-default variables interpolate at every node (EVO-1885)#84
Conversation
…bles interpolate at every node (EVO-1885)
Most node dispatch sites in journey-execution.workflow.ts omit journeyId, so
BaseNode.interpolateNodeData found no journey and left journey-default
{{variables}} as literal tokens at runtime (silently — the try/catch swallows
it). EVO-1882 fixed only send-webhook; the omission is systemic across the 17
interpolating nodes.
Single-point fallback: resolve the journey id as input.journeyId ?? session.journeyId.
session.journeyId is a scalar column present on both the cache (CachedJourneySession)
and DB session shapes, so one change covers all current and future nodes (including
conditional via selectiveInterpolateNodeData). Guard the query on a resolved id —
findOne({ where: { id: undefined } }) drops the condition and would return an
arbitrary journey's defaults.
New base.node.spec.ts covers fallback, input precedence, the no-id guard, and
session-variable no-regression.
There was a problem hiding this comment.
Sorry @daniloleonecarneiro, you have reached your weekly rate limit of 500000 diff characters.
Please try again later or upgrade to continue using Sourcery
dpaes
left a comment
There was a problem hiding this comment.
Approved — EVO-1885.
Option B verified against source: interpolateNodeData resolves input.journeyId ?? session.journeyId with an id-guard (also kills the latent findOne({id: undefined}) bug). Confirmed session.journeyId is a scalar column present on both the DB and cached (CachedJourneySession.journeyId) shapes, so the fix closes all 21 dispatch sites that omitted journeyId (conditional included via selectiveInterpolateNodeData). AC2 preserves input precedence; no session/workflow-variable regression. Nit: the new spec exercises only the cache path (DB-fallback untested, LOW).
Note: evo-flow-community CI does not run jest/tsc — tests author-reported. Merging (squash) to develop.
Summary
Follow-up to EVO-1882, which fixed
journeyIdfor the Send Webhook node only. The audit that card required revealed the omission is systemic: of the 17 node executors that interpolate, most dispatch sites injourney-execution.workflow.tsomitjourneyId.BaseNode.interpolateNodeDataresolves journey-level variable defaults viajourneyRepository.findOne({ where: { id: input.journeyId } }). WithjourneyIdundefined the lookup found nothing (silently — thetry/catchswallows it), so any{{variable}}backed by a journey default was left as the literal token at runtime. Session/workflow variables were unaffected.Fix (Option B — single-point fallback):
input.journeyId ?? session.journeyId.session.journeyIdis a scalar column present on both the cache (CachedJourneySession) and DB session shapes, so one change covers all current and future interpolating nodes — includingconditionalviaselectiveInterpolateNodeData.findOne({ where: { id: undefined } })drops the condition and would return an arbitrary journey's defaults — the guard also fixes that latent bug.Test plan
tsc -bclean.base.node.spec.ts(no prior spec exercisedinterpolateNodeDatainternals — node specs stub it): fallback tosession.journeyId,input.journeyIdprecedence, the no-id guard, and a session-variable no-regression case.temporalsuite green: 24 suites / 138 tests (the 4 failures on a bare run are pre-existingEVOAI_CRM_API_TOKENenv gating in unrelated assign/transcript specs; they pass with the token set and this change doesn't touch them).Notas
journeyId?interface churn across 16 node inputs.developwhich already contains EVO-1882 (fix(journey): pass journeyId to send-webhook activity so journey-default variables interpolate (EVO-1882) #83).