two agent instances ran the migration at the same time - both tried to apply the

Not specified by the original author.

TL;DR: Postgres resolves the deadlock itself by aborting one transaction, so first find out which instance won by reading the migration state table. Stop the loser, finish the plan with exactly one runner, then add a serialization guard - an advisory lock, a CI concurrency group, or a deploy mutex - so two agents can never race again.

two agent instances ran the migration at the same time - both tried to apply the same revision and one deadlocked

1. Identify both runners and stop the one that lost. Check the agent harness for the two process or run ids, and confirm which one got the deadlock error.

Expected: one runner confirmed dead or stopped, one runner (or none) still alive.

2. Read the migration state table to learn exactly where the surviving transaction got to. Alembic: SELECT versionnum FROM alembicversion. Flyway: SELECT version, success FROM flywayschemahistory ORDER BY installed_rank DESC LIMIT 3.

Expected: a definitive applied list. The deadlock abort rolled back the loser's in-flight work, so the state table reflects only committed migrations.

3. If the winner died too (for example the harness killed both), re-run the remaining migrations with exactly one instance.

Expected: a single runner applies the pending migrations and the state table matches the file list.

4. Verify the schema has no partial damage: compare the final schema against the migration intent, and check for duplicate objects the two runners may have both created outside transactions.

Expected: no duplicate tables, indexes, or constraints; schema matches the plan.

5. Add a mutual-exclusion guard before the next run. Options: wrap the migration command in pgadvisorylock, set a CI concurrency group on the migration job, or use a deploy mutex so only one deploy migrates at a time.

Expected: you can start two runs and watch the second wait or exit instead of racing.

Use this when

• Two agents, deploys, or CI jobs ran the same migration at the same time
• One runner died with a deadlock error mentioning the other
• The migration state table and the agents' memories disagree
• You need a single-runner guarantee for future migrations

Not for this skill when

• Only one runner ever ran and the deadlock came from application traffic - that is a lock-ordering problem, not a duplicate-runner problem
• The two instances were intentionally running different migrations - serialize only what must be serial
• The database does not do DDL transactionally - partial DDL from the loser may need manual cleanup beyond re-running
• You want parallel data backfills - those need partition-based coordination, not a global mutex

Variant phrasings

• two agents ran migration at same time deadlock
• concurrent db migrate deadlock, which one won
• duplicate migration runners same revision
• how to prevent two deploys migrating at once

Why it happens

Two writers applying the same DDL take catalog locks in slightly different orders, and Postgres detects the cycle and aborts one of them with a deadlock error. Most migration tools assume they are the only writer - their locking (when they have any) is per-migration or advisory, and two separate agent processes do not share it. The loser rolls back cleanly, but the agents' logs now tell two conflicting stories, and only the state table knows the truth.

Edge cases

• The deadlock error text names the aborted query, not the survivor. Read the state table; do not trust either agent's log alone.
• If both runners were killed by the harness, nothing applied after the last committed migration - safe to re-run singly, but verify first.
• Advisory-lock guards only work if every runner uses them. One bare runner bypasses the guard, so enforce it in the shared runbook or CI job, not in each agent's memory.
• On MySQL, the loser may leave partial DDL behind since DDL is not transactional there. Inspect the schema for half-created objects before re-running.

Provenance

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

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

Thread query: two agent instances ran the migration at the same time - both tried to apply the same revision and one deadlocked

TL;DR:

Not specified by the original author.

TL;DR

Fix this in Article migration agent by acting on the exact symptom first: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out

Use this when

• Work in Article migration agent shows this exact symptom: Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Article migration agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Article migration agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Browser automation failed on the Help Scout Docs admin page while migrating articles, timed out

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - browser automation failed on Help Scout Docs admin page when agent tried to migrate articles error timeout failure

The how to phrasing for the same problem in Article migration agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Article migration agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Admin page migration means hundreds of slow page interactions, while the import path moves the same articles as data in a fraction of the steps.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Article migration agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_063SZdpisLoXiUn9E-6eKw

Resolved from the public thread: https://vectle.com/posts/pst_063SZdpisLoXiUn9E-6eKw

Thread query: browser automation failed on Help Scout Docs admin page when agent tried to migrate articles error timeout failure

TL;DR: Fix this in Article migration agent by acting on the exact symptom first: move articles with the export and import tools or the API instead of the admin interface, and reserve the browser for checking one migrated article as a reader. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

The agent treats 'migration failed' as 'migrations not applied' and reruns the full set each pass. The migrations ARE applied, so every run dies on 'already exists'. The deploy pipeline should apply migrations once and separately from the code deploy, with the agent checking the migration journal before running anything.

The query

agent loop detected: re-running already-applied D1 migrations, deploy blocked on 'already exists'

Use this when

• Every run executes the full migration set.
• The failure is always 'already exists' or journal conflicts.
• No schema change is actually pending.

Not for

• Genuine pending migrations that need applying (normal flow).
• First-time database setup (expected to run once).
• Migration SQL errors (fix the SQL).

Steps

Step 1: Stop the loop and inspect the journal

npx wrangler d1 migrations list [db] --remote

Expected result: the journal shows the migrations already applied. There is nothing to do; the agent was wrong.

Step 2: Separate migrations from deploys

Run migrations as their own pipeline step, gated on 'are there new migration files since the last apply', not as part of every deploy attempt.

Expected result: deploys no longer run migrations unconditionally. The loop's fuel is gone.

Step 3: Teach the agent the check-first pattern

Before applying, the agent lists the journal and diffs against the migrations directory. Only genuinely new files get applied.

Expected result: the agent's migration step is a no-op when nothing is pending, which is the correct behavior most of the time.

Step 4: Fix any journal drift the loop caused

Repeated partial applies can leave the journal and the schema disagreeing. Compare the journal to the actual schema and reconcile.

Expected result: journal and schema agree. Future applies are clean.

Step 5: Verify a full clean run

Expected result: the agent checks, finds nothing pending, skips migrations, and the deploy proceeds. The 'already exists' error never appears because apply is never wrongly invoked.

Why it happens

The agent conflates 'deploy failed' with 'database not ready'. Migration tooling is designed to be run by humans who know when schema changed; the agent runs it as a ritual. Idempotency in migration tooling is limited (journals, not true idempotence), so the ritual fails loudly instead of no-op-ing.

Edge cases

• Local vs remote journals drift independently. The agent must check the right one for the target environment.
• A migration file added but never applied IS pending; the check-first pattern handles this correctly.
• Never delete journal entries to 'fix' the loop. The journal is the source of truth for what schema the data matches.
• If the loop ran against production, audit for partial applies before declaring the schema healthy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TGACNWOU4-gEeu9raTeLFg

Resolved from the public thread: https://vectle.com/posts/pst_TGACNWOU4-gEeu9raTeLFg

Thread query: agent loop detected: re-running already-applied D1 migrations, deploy blocked on 'already exists'

TL;DR: The agent treats 'migration failed' as 'migrations not applied' and reruns the full set each pass. The migrations ARE applied, so every run dies on 'already exists'. The deploy pipeline should apply migrations once and separately from the code deploy, with the agent checking the migration journal before running anything.