[harsh-thakkar7]

Que tipo de Pull Request es?

• Mejoras
• Bug
• Docs / tests

Descripción

Fixes #877.

gotoFlow waited once using flowInstance.ctx.options.delay, which contains the final answer's options, and then sent the target answers without applying their individual delays. Consequently, consecutive delayed addAnswer messages could be sent immediately, and the initial wait could use the wrong answer's delay.

Changes

• Replace the single flow-level wait with a wait before each target answer.
• Use each answer's configured delay, falling back to the bot's general delay exactly like sendFlow.
• Strengthen the existing issue regression with two delayed answers and timestamp assertions for both intervals.
• No public API or flow-definition changes.

Verification

• The strengthened regression failed before the fix because the second answer was not delayed.
• Targeted gotoFlow tests: 6/6 passed.
• pnpm test: all 29 monorepo test projects passed.
• pnpm --filter @builderbot/bot build: passed.
• ESLint and Prettier checks for both changed files: passed.

[leifermendez]

Antes de aprobar, necesitamos corregir una regresión en la interacción entre gotoFlow y el timeout de la cola. La espera por nodo soluciona el problema original, pero ahora las esperas se acumulan dentro del callback de un elemento cuyo timeout sigue corriendo. Si vence, el rechazo puede quedar sin manejar y terminar el proceso; si la aplicación captura globalmente ese rechazo, el bucle sigue enviando después de la cancelación.

Lo reproduje en 29c014603b3cedfaef458b6c13c23b9079746296, comparándolo con la base cb24cf93f0efe7d7d3cc586223115b44f0dc8b4f, con Node 24.19.0 y usando createBot, createFlow, addKeyword y TestTool:

• Flujo inicial: addKeyword('start').addAction(async (_, { gotoFlow }) => gotoFlow(target)).
• Destino: tres addAnswer (A, B, C), cada uno con { delay: 200 }.
• Configuración de createBot: { queue: { timeout: 450, concurrencyLimit: 15 } }.
• Al enviar start mediante el provider de prueba, la base termina con exit 0; el head termina con exit 1 y Error: Queue item timeout after 450ms.
• Con un listener de unhandledRejection para observar la continuación, el head todavía envía C después del timeout, aproximadamente a los 808 ms.

El timeout de 450 ms solo acorta la reproducción; el predeterminado de createBot es 50000 ms. La debilidad de cancelación ya existía, pero este cambio hace que la misma entrada y configuración de gotoFlow ahora la active. Los 6 tests de gotoFlow y los 208 tests del paquete pasan, por lo que esa interacción no está cubierta actualmente.

¿Podrías mantener la corrección por nodo y agregar un manejo controlado del timeout, propagando y respetando la cancelación, junto con un test de integración que exceda el timeout durante gotoFlow? El test debería comprobar que no haya rechazo no manejado ni envíos posteriores a la cancelación. Aumentar el timeout solamente no resuelve ese segundo problema. Gracias por trabajar en esta corrección.