mirror of
https://github.com/Luchexx/wacrm.git
synced 2026-11-02 09:19:51 +00:00
59dbf27f43
Two defects that together produce the reported symptom — automation logs that read `status: 'success'` with `steps_executed: []`. 1. The dispatch loop in the inbound webhook was fire-and-forget inside the route's `after()` block. `after()` only keeps the function alive for promises it can see, so the run could be frozen after the log row was inserted but before any step executed. This is the same failure mode as issue #301, recurring one level down — the comments on the AI auto-reply and `message.received` dispatches immediately below already spell out the invariant this violated. Now awaited; the per-iteration `.catch` is kept so one trigger type can't skip the rest of the loop. 2. `executeAutomation` seeded the log row with `status: 'success'` before running anything. A run that died mid-flight therefore left a permanent success with no steps, indistinguishable from an automation that genuinely had nothing to do. Seeded as `'failed'` instead, so the status only becomes success if execution actually reaches a terminal path. No migration needed — 'failed' is already in the column's CHECK constraint, and every terminal path overwrites it. Two more points from the issue are deliberately not addressed here, as both change existing behaviour and want a maintainer decision: switching `contains` keyword matching to word boundaries (would alter which automations fire for current users) and re-opening a closed conversation on an inbound reply. Refs #409. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| (auth) | ||
| (dashboard) | ||
| api | ||
| join | ||
| globals.css | ||
| icon.tsx | ||
| layout.tsx | ||
| page.tsx | ||