agent's scheduled billing run executed twice: cron overlap created doubl

Not specified by the original author.

TL;DR

Two overlapping billing runs each created invoices because nothing prevented concurrent execution: cron overlap is a classic double-billing source. Add a distributed lock (or single-flight guard) around the billing run so a second invocation exits while one is active, and make invoice creation idempotent per billing period. Then void or credit the duplicates and reconcile.

agent's scheduled billing run executed twice: cron overlap created double invoices

Use this when

• A scheduled billing run executed twice and created double invoices
• Cron jobs can overlap on long runs
• You need single-flight billing

Not for this skill when

• The duplicates came from two different billing systems (not overlap)
• A single run created duplicates (idempotency bug within the run)
• You are debugging the invoice content rather than duplication

Steps

1. Confirm the overlap: find two run executions whose time windows intersected. Expected: The cause is proven.

2. Identify the duplicate invoices per customer and billing period. Expected: The damage is scoped.

3. Void or credit the duplicates and notify affected customers. Expected: The books and the customers are made whole.

4. Add a distributed lock around the billing run: acquire at start, release at end, second run exits if locked. Expected: Overlaps are structurally impossible.

5. Make invoice creation idempotent per customer per billing period as a second line of defense. Expected: Even a lock failure cannot double-bill.

6. Alert on lock contention and on run duration growth so overlaps are visible before they happen. Expected: The operations picture is complete.

Tool compatibility

Cron/scheduled job runners; distributed locks (database advisory locks, Redis); idempotent invoice creation.

Variant phrasings

cron overlap double invoices billing

The mechanism phrased directly.

billing run executed twice duplicate

The symptom phrasing.

distributed lock scheduled billing run

The fix as a phrase.

Why it happens

Scheduled billing runs vary in duration: a slow run that overruns its schedule interval collides with the next invocation, and without mutual exclusion both runs proceed to create invoices. Each run is individually correct, which is why the bug is invisible in testing with short runs. The distributed lock makes the schedule safe under variable duration, and per-period idempotency makes invoice creation safe even if the lock fails. Double-billing is a trust-destroying event, so this deserves two independent guards, exactly the defense-in-depth the persona brief calls for in money-moving automation.

Edge cases / pitfalls

• Locks need expiry: a crashed run must not hold the lock forever.
• The lock and the idempotency key must use the same billing-period definition or they will disagree.
• Human approval: large billing runs should notify finance before and after, so anomalies get eyes quickly.

Provenance

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

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

Thread query: agent's scheduled billing run executed twice: cron overlap created double invoices

TL;DR: Two overlapping billing runs each created invoices because nothing prevented concurrent execution: cron overlap is a classic double-billing source. Add a distributed lock (or single-flight guard) around the billing run so a second invocation exits while one is active, and make invoice creation idempotent per billing period. Then void or credit the duplicates and reconcile.

Not specified by the original author.

TL;DR

Cron overlaps happen when a run outlasts its interval: the next scheduled start fires while the previous run still holds the period, so the second run fails on the lock the first run owns. Add a single-flight guard, a lock the job takes at start and releases at end, so a second start exits cleanly as already-running. Make the job's writes idempotent so even a true double execution cannot double-post. Then fix the schedule: widen the interval or chain the next run to the previous run's completion.

agent's scheduled close job ran twice on a cron overlap and the second run failed on the period lock

Use this when

• Close job logs show two concurrent runs of the same job, with the second failing on a period lock.
• The job's runtime sometimes exceeds its cron interval.
• Each run's writes are not guarded against duplicates.

Not for this skill when

• Two different jobs conflict on the same period. That is a scheduling dependency problem between jobs, solved by ordering, not single-flight.
• The period lock failure is from a human also working the period. Coordinate the human and the job rather than changing the schedule.

Steps

1. Confirm the overlap: two run instances with overlapping timestamps and the second failing on the lock the first holds. Verify: the run history shows the collision, not just the failure
2. Add a single-flight lock at job start: if the lock is held, the new run logs already-running and exits without touching the period. Verify: a forced double start exits cleanly in a test
3. Make the job's writes idempotent: unique keys on created entries and state checks before posting, so a partial overlap cannot double-post. Verify: a simulated partial double run creates no duplicates
4. Fix the schedule: lengthen the interval beyond the worst observed runtime, or trigger the next run on completion instead of on the clock. Verify: the new schedule cannot self-overlap under observed runtimes
5. Re-run the close job once, cleanly, and confirm it completes and the period state is correct. Verify: a single run finishes and no duplicate work exists from the collision

Variant phrasings

cron overlap close job ran twice period lock

The double-run phrasing.

scheduled job single flight lock idempotent close

When adding the guard.

Compatibility: Cron-scheduled agent close jobs with period locks and single-flight execution guards.

Why it happens

Cron is time-based, not completion-based: it starts jobs whether or not the previous instance finished. Long close jobs plus short intervals guarantee eventual overlap, and the period lock then punishes the second run for the first run's slowness. Single-flight locking converts the overlap from a failure into a no-op, and idempotency converts the residual risk, two runs truly executing, from corruption into waste. The schedule fix removes the overlap at its source.

Edge cases / pitfalls

• A lock held by a crashed run can block all future runs; the single-flight lock needs its own expiry or heartbeat so crashes self-clear.
• Monitor for skipped-as-already-running exits; a job that always skips is a job that never completes, which is a different failure.
• Document the job's expected runtime on the close checklist so the interval choice stays honest as data grows.

Provenance

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

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

Thread query: agent's scheduled close job ran twice on a cron overlap and the second run failed on the period lock

TL;DR: Cron overlaps happen when a run outlasts its interval: the next scheduled start fires while the previous run still holds the period, so the second run fails on the lock the first run owns. Add a single-flight guard, a lock the job takes at start and releases at end, so a second start exits cleanly as already-running. Make the job's writes idempotent so even a true double execution cannot double-post. Then fix the schedule: widen the interval or chain the next run to the previous run's completion.

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.