Skip to content

fix(journey): wait multi-output routing (EVO-1912)#89

Open
daniloleonecarneiro wants to merge 1 commit into
developfrom
danilocarneiro/evo-1912-jornadas-wait-multi-saida-quebrado-handles-wait-successwait
Open

fix(journey): wait multi-output routing (EVO-1912)#89
daniloleonecarneiro wants to merge 1 commit into
developfrom
danilocarneiro/evo-1912-jornadas-wait-multi-saida-quebrado-handles-wait-successwait

Conversation

@daniloleonecarneiro

Copy link
Copy Markdown

Resumo

O nó Wait com múltiplas saídas (enableFallback ou waitType=time_or_condition) desenha no FE os handles wait-success e wait-otherwise e cria arestas com esses sourceHandle. Mas o backend roteava por nodeData.successNodeId / otherwiseNodeId / nextNodeId — campos que o FE nunca grava. Com eles nulos, o workflow caía no fallback outgoingEdges[0].target sem olhar o handle, tornando o roteamento dependente da ordem de inserção das arestas → não-determinístico (mesma classe da EVO-1902/D13, porém pior).

Fix (lado backend)

Roteamento por edge.sourceHandle, consistente com conditional/split:

  • wait.node.ts: hasMultipleOutputs() + resolveWaitHandle() mapeia o resultado do wait → handle (success → wait-success, timeout/cancelled → wait-otherwise); waits de saída única retornam null. Constantes SUCCESS_HANDLE/OTHERWISE_HANDLE. Roteamento legacy por id em node-data preservado.
  • action-nodes.activities.ts: nova activity resolveWaitHandle.
  • journey-execution.workflow.ts: no resume do wait, resolve o handle e seta nodeResult.nextNodeHandle (sobrevive ao reassign genérico nextNodeId = nodeResult.nextNodeId); o bloco existente de match sourceHandle === nextNodeHandle escolhe o destino determinístico.

Waits de saída única não são afetados (handle null → segue a única aresta).

Testes

  • wait.node.spec.ts: 11 testes (handles success/timeout/cancelled, single-output, legacy id-based).
  • tsc -p tsconfig.json --noEmit: limpo.
  • jest src/modules/temporal: 147 passam; as 4 falhas restantes são pré-existentes (EVOAI_CRM_API_TOKEN nos nodes EVOAI, independentes).

EVO-1912

…ait-otherwise (EVO-1912)

O no Wait com multiplas saidas (enableFallback / time_or_condition) roteava por
nodeData.successNodeId/otherwiseNodeId/nextNodeId — campos que o FE nunca grava.
Com eles nulos, o workflow caia no fallback outgoingEdges[0].target sem olhar o
handle, tornando o roteamento dependente da ordem de insercao das arestas
(nao-deterministico).

Agora o backend resolve o handle de saida a partir do resultado do wait
(success -> wait-success, timeout/cancelled -> wait-otherwise) e o workflow
casa edge.sourceHandle === nextNodeHandle, igual conditional/split. Waits de
saida unica retornam null e seguem a unica aresta. Roteamento legacy por id em
node-data preservado para journeys que o persistam.

- wait.node.ts: hasMultipleOutputs() + resolveWaitHandle() + constantes de handle
- action-nodes.activities.ts: activity resolveWaitHandle
- journey-execution.workflow.ts: resolve handle no resume do wait e seta
  nodeResult.nextNodeHandle (sobrevive a reassign generica de nextNodeId)
- wait.node.spec.ts: 11 testes (handles, single-output, legacy id-based)

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry @daniloleonecarneiro, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

@daniloleonecarneiro daniloleonecarneiro self-assigned this Jun 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant