GitHub user Ashfaqbs added a comment to the discussion: Human-in-the-loop approval: pluggable approver (decision model first, human fallback) - design discussion for #1067
Good catch — that's exactly the race I hadn't pinned down: a decision replayed on recovery, but the downstream effect's own completion was never checkpointed. Carrying the pending-approval id as the idempotency key into that call is the right fix, and recording succeeded/failed/unknown next to the verdict matters a lot — without "unknown" you can't tell a timeout from a dispatch that genuinely never went out, which is the difference that matters for something like an ad-spend or trade action you can't just blindly retry. Keeping the consumed-action check and the dispatch record in the same transaction (thanks for the gist) closes the window where the effect fires but we forget we dispatched it. I'd fold this into question 1 above — it's really the audit-trail/outcome-recording half of that question. Mind if I link your comment from the issue body as the answer to that part? GitHub link: https://github.com/apache/flink-agents/discussions/1304#discussioncomment-19200423 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
