agent's stripe meter reporting double-counted usage: missing idempote

Not specified by the original author.

TL;DR

Stripe usage records without idempotency keys double-count when the agent retries: two records for one consumption event inflate the invoice. Attach a deterministic idempotency key to every usage record (derived from the event id and billing period), so retries collapse into one record. Then audit recent invoices for inflated usage and credit the difference.

agent's stripe meter reporting double-counted usage: missing idempotency on usage records

Use this when

• Stripe metered usage is double-counted after agent retries
• Usage record creation has no idempotency key
• Invoices show inflated consumption

Not for this skill when

• Usage is under-counted (a metering pipeline gap, not idempotency)
• The invoice total is wrong for a fixed-price item
• You are debugging the upcoming invoice preview

Steps

1. Confirm the double-count: compare usage records against your application's consumption events for the period. Expected: The duplication is proven.

2. Derive a deterministic idempotency key per consumption event (event id plus billing period). Expected: Every event maps to exactly one key.

3. Attach the key to usage record creation and make the agent reuse it on retry. Expected: Retries are idempotent.

4. Re-run the failed reporting path and confirm a single record per event. Expected: No duplicates are created.

5. Credit customers for the inflated invoices and add a duplicate-usage monitor. Expected: Past harm is repaired and future harm is caught.

6. Require idempotency keys on all meter writes in the agent's tool contract. Expected: The class of bug is closed.

Tool compatibility

Stripe usage records API idempotency keys; agent metering pipelines that report consumption to Stripe.

Variant phrasings

stripe usage records duplicate idempotency

The mechanism phrased as a fix.

agent meter double counting stripe

The agent-operations angle.

stripe metered billing duplicate usage records

The billing-symptom phrasing.

Why it happens

Usage records are additive: each one increases the billed quantity, so creating the same record twice bills twice. Agents retry on timeouts and errors as designed, but without an idempotency key Stripe cannot know the retry is a duplicate. A deterministic key turns create into upsert semantics: the same event always produces the same key, and Stripe collapses the retry. The bug is not the retry, which is correct behavior, but the missing key, which makes the retry unsafe. Guardrail: no meter write without a key.

Edge cases / pitfalls

• Keys must be deterministic per event, not random per attempt, or retries still duplicate.
• Backfills need the same key scheme or they will double-count against live reporting.
• Human review threshold: alert when reported usage jumps beyond a sane multiple of the trailing average.

Provenance

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

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

Thread query: agent's stripe meter reporting double-counted usage: missing idempotency on usage records

TL;DR: Stripe usage records without idempotency keys double-count when the agent retries: two records for one consumption event inflate the invoice. Attach a deterministic idempotency key to every usage record (derived from the event id and billing period), so retries collapse into one record. Then audit recent invoices for inflated usage and credit the difference.

Not specified by the original author.

TL;DR

Stripe redelivers webhooks until acknowledged, so a handler without an idempotency guard processes the same event twice: double fulfillment, double credits, double emails. Store every processed event id and skip events already seen, checking the store before any side effect. Make the guard the first line of the handler, not an afterthought.

agent's webhook handler processed the same stripe event twice: no idempotency guard

Use this when

• A Stripe webhook handler processed the same event twice
• You see duplicate side effects from webhooks
• Your handler lacks an event-id store

Not for this skill when

• Two different events arrived (that is normal, not duplication)
• The webhook signature fails (verification problem)
• You are debugging event delivery delays

Steps

1. Confirm duplication: find two handler executions with the same Stripe event id. Expected: The double-processing is proven.

2. Create a processed-events store (database table or cache) keyed by event id. Expected: The guard has a home.

3. At the top of the handler, check the store: if the event id exists, acknowledge and return without side effects. Expected: Duplicates are skipped.

4. Insert the event id in the same transaction as the side effect where possible. Expected: The check and the effect are atomic.

5. Replay a past event from the Stripe dashboard to prove the guard holds. Expected: Idempotent handling is verified.

6. Alert on duplicate delivery rates: a spike means Stripe is not getting your 200s. Expected: Delivery health is monitored.

Tool compatibility

Stripe webhooks and event ids; any datastore for the processed-event record.

Variant phrasings

stripe webhook duplicate event handling

The general problem phrasing.

stripe event idempotency guard

The fix as a phrase.

webhook processed twice stripe

The symptom phrasing.

Why it happens

Stripe's webhook delivery is at-least-once by design: if your endpoint is slow, errors, or returns a non-2xx, Stripe retries the same event, sometimes minutes later. A handler that performs side effects unconditionally will therefore execute them once per delivery. The event id is Stripe's deduplication handle, and the processed-event store turns the handler idempotent. This is the same exactly-once pattern as payout retries, applied to inbound events: the guardrail belongs at the entry point, before any business logic runs.

Edge cases / pitfalls

• Return 200 only after the side effect is durably recorded, or Stripe will retry a completed handler.
• The store needs a TTL or cleanup: event ids accumulate forever otherwise.
• Signature verification and idempotency are separate guards; you need both.

Provenance

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

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

Thread query: agent's webhook handler processed the same stripe event twice: no idempotency guard

TL;DR: Stripe redelivers webhooks until acknowledged, so a handler without an idempotency guard processes the same event twice: double fulfillment, double credits, double emails. Store every processed event id and skip events already seen, checking the store before any side effect. Make the guard the first line of the handler, not an afterthought.

Not specified by the original author.

TL;DR

An outage ends and the retry logic holds the celebration in your warehouse. When Segment or the sending integration recovers, queued retries, client resends, and the agents own replay can all deliver the same usage events more than once, and a warehouse that appends without checking event identity counts every delivery as new behaviour. Prove the duplication at event level, deduplicate the poisoned window on the event identifier, fix the retry path so recovery delivers once, and restate the churn numbers the flood corrupted.

agent retry storm after a Segment outage flooded the warehouse with duplicate usage events: churn counts doubled

Use this when

• Usage volume and churn related counts jumped to roughly double right after a Segment outage or degradation
• Raw event tables show identical events, same event identifier or same user, event, and timestamp, arriving more than once
• The spike begins at the recovery moment, not during the outage itself

Not for this skill when

• Server side product logs confirm usage genuinely doubled, for example a launch, making the warehouse right
• Duplicates exist but churn counts are unaffected because the model already deduplicates, making this a storage hygiene issue only

Steps

1. Prove duplication at the event level. In the warehouse raw table, group events in the suspect window by their event identifier, or by user, event name, and timestamp where identifiers are absent, and count deliveries per event. A healthy window shows one delivery per event, a retry storm shows a clean multiple, and the multiple itself often reveals how many retry layers fired. Verify: the duplication factor and its window are measured from raw events
2. Map every retry layer that touched the window. List the senders, the product instrumentation, any server integration, the Segment functions or protocols in the path, and your own agents replay behaviour, and determine which layers retried and how their retry identities work, because deduplication in the warehouse is the seatbelt while the retry design is the brakes, and you need both fixed. Verify: each retry layer and its behaviour during the outage is identified
3. Deduplicate the poisoned window safely. Build the dedupe on the strongest identity available, preferring the event unique identifier, keeping the earliest delivery as canonical, and write the deduplicated result as the corrected table or view the churn model reads, rather than deleting rows from the raw table, so the evidence of the flood survives for audit and the correction is reversible. Verify: the deduplicated view returns event counts matching pre outage patterns and the raw table is untouched
4. Restate the affected metrics. Recompute usage, churn, and health inputs for the flood window from the deduplicated data, compare them against the doubled figures stakeholders may have seen, and issue a short correction note naming the window and the cause, since doubled churn numbers travel fast and a quiet fix leaves the false figure alive in decks you will never see. Verify: the window metrics are restated and the correction note is issued
5. Fix delivery semantics going forward. Ensure the sending path carries a stable event identifier generated once per real event, not per attempt, make the warehouse load or the models source view deduplicate on it permanently, and confirm any replay tooling the agent uses reuses original identifiers instead of minting new ones that defeat deduplication entirely. Verify: a test double delivery of the same event lands once in the model source
6. Review the outage playbook. Add a recovery checklist step that watches for volume multiples in the hours after any ingestion outage and holds downstream churn reporting until the duplication check passes, because the hours after an outage are exactly when every retry layer does its damage and when fresh numbers are most hungrily consumed. Verify: the recovery checklist includes the duplication check with a named owner

Why it happens

Modern event pipelines are built from layers that each promise at least once delivery, which is the honest way to avoid losing events during outages. Stacked together without a shared event identity, at least once per layer multiplies into several times in the warehouse. The system worked as each layer designed it, and the composition is the defect. A stable identifier plus deduplication at consumption converts the stack back into effectively once, which is the only semantics churn counting can survive.

Compatibility: Segment ingestion and delivery, warehouse raw event tables, event identifiers, and dbt or SQL deduplication in churn models, in current versions.

Variants and edge cases

Segment outage retry duplicates warehouse events

['The direct phrasing. Stable identifiers created once per event are what make deduplication possible at all, audit where yours are minted.']

usage counts doubled after outage duplicate events

['The measurement variant. A volume that lands near an exact multiple of baseline is a duplication signature, genuine growth is never that tidy.']

churn counts wrong duplicate usage events fix

['The restatement variant. Correct through a deduplicated view over preserved raw data, deletions destroy the audit trail and the ability to verify the fix.']

Edge cases to work through before you close the incident:

• Client side retries during the outage window can mint genuinely new identifiers for resent events in some SDK configurations. Where that happened, fall back to a user, event, and timestamp fingerprint and accept a small residual error, stated openly.
• Deduplication keys must include the event name and user, not the identifier alone, if identifiers are only unique per source. Test the key across all sources the warehouse blends.
• Late duplicates can arrive days later from offline mobile clients. Keep the deduplication in the always on model layer, not in a one time cleanup of this window.

Provenance

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

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

Thread query: agent retry storm after a Segment outage flooded the warehouse with duplicate usage events: churn counts doubled

TL;DR: An outage ends and the retry logic holds the celebration in your warehouse. When Segment or the sending integration recovers, queued retries, client resends, and the agents own replay can all deliver the same usage events more than once, and a warehouse that appends without checking event identity counts every delivery as new behaviour. Prove the duplication at event level, deduplicate the poisoned window on the event identifier, fix the retry path so recovery delivers once, and restate the churn numbers the flood corrupted.