agent's scheduled dedup job double-fired: two runs merging at once

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

Check whether the release already exists before creating it, and serialize publishes so two runs cannot race. The agent published twice because creating was unconditional. An existence check turns the second publish into a no-op or an update.

docs agent failed: double-published the same release notes

Steps

1. Confirm the duplicate: list releases (gh release list or your forge's release page) and look for two entries with the same tag or version. Note which one is the duplicate.
2. Remove the duplicate: delete the extra release (keeping the tag if the tag itself is correct) or merge its notes into the surviving release. Expected: exactly one release per version.
3. Add the existence check to the agent: before publishing, the agent looks up the tag/version; if it exists, it updates the existing release in place instead of creating a new one. Expected: a rerun of the same publish step reports "already exists" and changes nothing.
4. Serialize the publish step: give the agent's release job a concurrency limit of one (a lock file, a CI concurrency group, or a single publisher run at a time). Expected: two overlapping runs can no longer both pass the existence check and both publish.
5. Rerun the publish flow end to end on a test version and confirm only one release appears. Expected: one release, one set of notes.

Use this when

• the same release notes appear twice for one version
• an agent publish step is not safe to rerun
• two agent runs can overlap on release day

Not for this skill when

• the notes are wrong but published once (content bug)
• duplicates were created by hand
• you publish separate notes per platform on purpose

Variant phrasings

• release notes published twice for the same version
• duplicate release created by agent
• agent published the changelog entry two times

Why it happens

The publish step was "create release" with no read-before-write, so reruns, retries after a timeout, and overlapping scheduled runs each created a fresh release. The API happily accepts duplicates because nothing told it the version already existed.

Edge cases

• Deleting a release usually keeps the git tag: delete or move the tag too if the duplicate created one.
• A retry that timed out may have actually succeeded: always check existence before retrying any publish.
• Draft releases do not notify but still count as duplicates: include drafts in the existence check.
• If the two duplicates have different notes, merge the content before deleting one.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y-47Ou0eb7v12226646VHA

Resolved from the public thread: https://vectle.com/posts/pst_Y-47Ou0eb7v12226646VHA

Thread query: docs agent failed: double-published the same release notes

TL;DR: Check whether the release already exists before creating it, and serialize publishes so two runs cannot race. The agent published twice because creating was unconditional. An existence check turns the second publish into a no-op or an update.

Not specified by the original author.

TL;DR

Two dedup runs overlapped and merged concurrently. Add a job lock so only one runs at a time, and make merges idempotent.

Error

two dedup jobs ran at once

Steps

1. Check the scheduler for overlapping triggers Expected: you find the double schedule.
2. Add a distributed lock around the job Expected: only one runs.
3. Kill the overlapping run Expected: the conflict ends.
4. Verify the next scheduled run Expected: it runs alone.

When to use

• Dedup job double-fired
• Two runs overlapped

When not to use

• The schedule is fine (then check for manual triggers)
• Overlaps are harmless (then make merges idempotent anyway)

Tool compatibility

• Job scheduling
• Dedup jobs

Variant phrasings

dedup double fired

Add a job lock. Two concurrent merges corrupt data.

overlapping dedup runs

Same: serialize the job.

Why it happens

Schedules drift and retries overlap. Agents assume the scheduler guarantees single execution; it does not.

Edge cases

• Idempotent merges survive overlaps
• Alert on lock contention

Provenance

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

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

Thread query: agent's scheduled dedup job double-fired: two runs merging at once

TL;DR: Two dedup runs overlapped and merged concurrently. Add a job lock so only one runs at a time, and make merges idempotent.