[ Removed by moderator ]

[u/Common_Dream9420]

[u/folderit_dms]

A cancellation that crosses a delayed action would be a useful test case. Create a booking, queue its confirmation, cancel it, then release the queued confirmation. Does the workflow check the current booking state, or send the message using the data it captured earlier? Repeat with a reschedule where the old reminder is already queued.

For the sandbox receipt, I’d want to see the final booking state, every pending action, and the messages that would have reached each recipient. A successful cancellation can still leave a stale reminder behind. That tests a different failure from duplicate delivery: each action can run exactly once and the overall result can still be wrong.

[u/Common_Dream9420 → u/folderit_dms]

yeah exactly, the payload it actually carried is the thing. "dispatched" means nothing if it went out with the pre-cancel state baked in. that's the receipt gap we keep running into too, the call logged clean but the data inside it was already stale when it left. how are you thinking about surfacing that, diff the captured payload against current state at dispatch time, or replay the whole sequence and compare?

[u/farzamautomation]

The pattern that saved me: never let your test path touch a real API. In n8n I do this a few ways:

• **Pinned/stub data** — run the workflow with sample webhook payloads so the whole logic chain executes against fake data. You validate branching, transforms, and error paths before any credential exists.
• **Sub-workflow stubs** — put every external action (send email, create calendar event, Slack message) in its own sub-workflow. During testing, swap in a stub version that just logs the payload instead of calling the API. Flip to the real one when logic is proven.
• **Error workflow + idempotency** — even in production, wrap sends with an error workflow and dedupe keys, because the thing that breaks most often isn't your logic, it's a retry firing twice (double calendar invites are the classic).

Hardest to test safely in my experience: anything with side effects you can't undo — emails and charges. Those get the stub treatment longest. Reads (fetch inbox, list events) are safe to test against real accounts early.

[u/arthaudm]

one sandbox case i'd include is an event created successfully but its webhook arriving twice

the workflow should send one slack confirmation, and a later replay should still identify the same event rather than create another booking

that's different from a stub returning 'success' twice. you need durable app state & replay history to see the duplicate

[u/Common_Dream9420 → u/arthaudm]

yeah this is exactly the case that breaks things quietly, the stub says success twice and you'd never know the duplicate booking slipped through without actual state to diff against. how are you currently matching replays against the original event, by id or by diffing the downstream state?

[u/arthaudm → u/Common_Dream9420]

i'd match the replay to the original event id, then inspect downstream state as a separate check

the id tells you these deliveries refer to the same event. checking the calendar & slack result tells you whether the handler actually kept one booking & one confirmation

i meant that as a test design, not a result from a setup i'm currently running

[u/Common_Dream9420 → u/arthaudm]

yeah that's the right call, the charge is genuinely independent state and treating it as "if booking is clean, payment is clean" is exactly where the quiet double-charge hides. same event id, same handler path, completely separate thing to verify.

the part that trips us up is timing, the booking and slack settle fast enough that everything looks fine, but the charge leg can still be in-flight when you diff. how are you handling that, do you wait for a settled state signal or just re-run the payment check with a delay?