agent's exception queue broke: sent 300 duplicate flags

Not specified by the original author.

TL;DR

The queue re-emitted the same flags because nothing marked them as sent. Give every flag a stable idempotency key (report ID plus rule ID), check the key before emitting, and the flood stops: each violation flags exactly once.

Error

agent's exception queue broke: sent 300 duplicate flags

Steps

1. Halt the flood: pause the queue consumer. Expected: no more duplicate flags go out.
2. Define the idempotency key for a flag: report ID plus rule ID plus expense line ID. Expected: a key that is identical for the same finding.
3. Before emitting, check whether the key was already emitted (a sent-set in durable storage). Expected: repeats are dropped.
4. Drain the backlog through the dedupe check, emitting only unseen keys. Expected: each real violation appears exactly once.
5. Clean up the duplicates already sent: notify reviewers which flags were repeats. Expected: reviewers trust the queue again.

When to use

• An exception queue emits duplicate flags at scale.
• Retries or restarts multiply the flags.

When not to use

• The flags are distinct real violations (high volume is correct).
• A single flag duplicated once (check the emit path, smaller fix).

Tool compatibility

• Custom exception queues in audit agents; reviewer dashboards.

Variant phrasings

Duplicate flags flooded reviewers

Same failure, impact-worded.

Exception queue re-emitted flags

Names the re-emission directly.

Why it happens

Queues retry, agents restart, and without idempotency every retry looks like a new flag. The sent-set is the memory that turns retries into safe no-ops.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Q-q2ue2yZACWHl6eeWM9kw

Resolved from the public thread: https://vectle.com/posts/pst_Q-q2ue2yZACWHl6eeWM9kw

Thread query: agent's exception queue broke: sent 300 duplicate flags

TL;DR: The queue re-emitted the same flags because nothing marked them as sent. Give every flag a stable idempotency key (report ID plus rule ID), check the key before emitting, and the flood stops: each violation flags exactly once.

Not specified by the original author.

TL;DR

The flagger keeps surfacing pairs that were already merged because it never learns what "done" looks like. Maintain an exclusion list of merged pair keys and filter every new flag batch against it before queueing. Flags for done work are noise; filter them at the source.

Error

(No error; the symptom is the review queue refilling with pairs that show as already merged.)

Steps

1. Confirm the flagged pairs are truly merged (check the survivor record). Expected: you verify it is redetection, not new duplicates.
2. Build the exclusion list from the merge ledger (pair keys of completed merges). Expected: the full done set.
3. Filter flag batches against the exclusion list before queueing for review. Expected: the queue holds only new work.
4. Fix the flagger to consult the exclusion list itself, not just the queue filter. Expected: done pairs never get flagged.
5. Monitor the filter rate; a sudden spike means the ledger or flagger drifted. Expected: early warning.

When to use

• Review queues refill with already-merged pairs.
• An agent flags the same pairs every run.
• After merges, flags do not clear.

When not to use

• Genuinely new duplicates (those should be flagged).
• Merge failures (different problem).

Tool compatibility

• Merge ledgers; flag and review queues.
• Agent filtering logic.

Variant phrasings

re-flagging merged duplicates

Exclude done pairs from flags.

review queue full of done work

Filter at the source.

Why it happens

Flagging and merging are separate steps with no shared memory. The flagger's input snapshot predates the merges, so it rediscovers what the merger already handled.

Edge cases

• Partial merges (one pair of three merged) need pair-level, not record-level, exclusion.
• The exclusion list must persist across runs; in-memory sets do not survive restarts.
• Reviewers who reject a merge need it removed from the exclusion list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Af-A8wRfZGIk1llxjWaWHQ

Resolved from the public thread: https://vectle.com/posts/pst_Af-A8wRfZGIk1llxjWaWHQ

Thread query: agent loop detected: re-flagging the same already-merged duplicates

TL;DR: The flagger keeps surfacing pairs that were already merged because it never learns what "done" looks like. Maintain an exclusion list of merged pair keys and filter every new flag batch against it before queueing. Flags for done work are noise; filter them at the source.

Not specified by the original author.

TL;DR

The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.

fraud agent loop detected: re-flagging the same transaction

Use this when

• Logs show the same transaction id flagged two or more times in one run.
• Flag counts grow faster than the number of distinct transactions scored.
• The loop clears on restart and then starts again from scratch.

Not for this skill when

• A rule engine fires on genuinely new transactions. That is rule tuning, not a loop.
• The queue grows because transaction volume grew. Check ingress before blaming the agent.

Steps

1. Confirm the loop: search run logs for repeated transaction ids inside one run id. Verify: one id appears three or more times under the same rule version.
2. Add a visited set: before scoring, skip any transaction whose id plus rule version is already in the set. Verify: re-running the batch flags zero already-seen transactions.
3. Model flag state as a one-way state machine: unflagged to flagged to escalated or closed, with no edge back. Verify: a flagged transaction can only move forward.
4. Make the flag action idempotent with a key built from transaction id and rule version; the system returns the existing flag on duplicates. Verify: a double POST returns the same flag id with no new row.
5. Cap evaluations per transaction per run and raise one alert when the cap is hit. Verify: a run that hits the cap raises the alert exactly once and moves on.

Variant phrasings

fraud agent keeps flagging the same transaction

Same loop, looser phrasing.

agent flags transaction twice

Duplicate-flag symptom search.

reflagging loop in fraud review

Loop-focused phrasing.

Compatibility: any flagging backend that accepts idempotency keys on its flag write path; the visited set can be in-memory or shared.

Why it happens

The evaluation loop treats every cycle as a fresh look with no memory. Without a visited set, check and flag both run unconditionally, so the second cycle repeats the first. Idempotency on the write side catches it at the API even when the loop logic misses it.

Edge cases / pitfalls

• Rule version changes are legitimate re-scores: include the version in the visited key so a new rule still gets one clean pass.
• Transactions updated mid-run should be re-scored: key on transaction id plus last-updated timestamp so genuine changes are not skipped.
• Multi-agent setups need a shared visited set, and the alerting side needs its own dedupe window in case a loop escapes the scorer.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_01wAota1bbLGnCacg6QtAA

Resolved from the public thread: https://vectle.com/posts/pst_01wAota1bbLGnCacg6QtAA

Thread query: fraud agent loop detected: re-flagging the same transaction

TL;DR: The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.