fraud agent timed out enriching transaction metadata after secondary rate limit

TL;DR

Secondary limits punish burst patterns per endpoint, not total volume. Cap concurrency per enrichment endpoint, cache enrichment results, and when enrichment times out, proceed with partial metadata flagged as incomplete rather than stalling the review.

fraud agent timed out enriching transaction metadata after secondary rate limit

Use this when

• Enrichment calls time out after a secondary limit engages.
• One slow enrichment endpoint stalls the whole review.
• The same transactions get enriched more than once per run.

Not for this skill when

• The primary quota is exhausted. That is a volume problem, not a burst problem.
• Enrichment returns wrong values. That is a data quality problem.
• The agent is slow for other reasons. Profile before blaming enrichment.

Steps

1. Split your limiter per enrichment endpoint instead of one global limiter. Verify: a hot endpoint throttles without slowing the others.
2. Cache enrichment results per transaction id for the run. Verify: repeat enrichments never call the API twice.
3. Set a per-call timeout on enrichment shorter than the review step budget. Verify: a slow enrichment fails fast.
4. On timeout, continue the review with partial metadata and mark the item as enrichment-incomplete. Verify: the review finishes and the gap is visible.
5. Backfill incomplete enrichments in a low-priority pass when limits recover. Verify: the gap closes without blocking the main queue.

Variant phrasings

secondary rate limit enrichment timeout

Same problem, common phrasing.

metadata enrichment throttled agent

Symptom-level search.

enrichment api timeout fraud review

Operational wording.

Compatibility: Metadata enrichment APIs (device, email, IP, identity) behind per-endpoint secondary limits.

Why it happens

Primary limits cap total calls, but secondary limits cap bursts per endpoint or per key, and enrichment fans out into several endpoints at once. The agent sees timeouts rather than clean 429s because the provider sheds load by slowing responses. Without per-endpoint pacing and a degrade path, one slow enrichment stalls every review behind it.

Edge cases / pitfalls

• Partial metadata can miss the signal that matters. Flag incomplete items for analyst review, do not auto-approve them.
• Backfill passes need their own pacing or they re-trigger the limit.
• Track which enrichment fields go missing most. A consistently slow endpoint may need replacing.
• Degrade decisions belong to the risk team. Write down what incomplete means for the final call.

Provenance

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