means already stored do not retry

Not specified by the original author.

TL;DR

Fix this in Apollo by acting on the exact message first: check the original job status before resubmitting, use the contact email as the dedupe key on any retry, and reconcile created counts against submitted counts before declaring the run complete. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.

Agent duplicated contacts after retrying a timed out Apollo bulk enrichment job

Use this when

• The operation in Apollo fails with this exact message: Agent duplicated contacts after retrying a timed out Apollo bulk enrichment job.
• The same failure repeats on retry with unchanged inputs.
• A run, import, export or alert is blocked until this item completes.

Not for this skill when

• The message is a permission or platform outage notice. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in Apollo, and copy the full message plus the record, account or list involved into the run notes. Verify: the error is reproduced on demand with a named record, not only seen in a log.
2. Apply the specific fix for this error: check the original job status before resubmitting, use the contact email as the dedupe key on any retry, and reconcile created counts against submitted counts before declaring the run complete. Verify: one named record now completes end to end with the correct result and the original message does not appear.
3. Check the neighbouring records that share the same source, mapping, workspace or settings, because this class of failure rarely affects only one record. Verify: the neighbouring records are listed and each is marked affected or clear.
4. Compare the result counts, fields or alerts against the source in Apollo so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation in Apollo on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
6. Record the fix, the triggering input and the verification result on the record so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

The first job had actually completed on the server after the timeout, so the blind retry created a second copy of every contact it had already enriched.

Variant phrasings

Agent duplicated contacts after retrying a timed out Apollo bulk enrichment job

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single record proof, then the full rerun.

How to fix this failure in Apollo

The how to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting this failure in Apollo

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

Compatibility: Apollo at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: agent duplicated contacts after retrying a timed out Apollo bulk enrichment job

TL;DR: Fix this in Apollo by acting on the exact message first: check the original job status before resubmitting, use the contact email as the dedupe key on any retry, and reconcile created counts against submitted counts before declaring the run complete. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one record, then rerun the full scope and reconcile the counts.

Not specified by the original author.

What an agent client should do on HTTP 503 temporarily_unavailable

TL;DR

A 503 with code temporarily_unavailable and retry kind none is a refusal, not a suggestion to try again quickly. Do not replay the identical request. Read the error's retry fields, note the failure, back off for minutes rather than seconds, and if the result is still needed after the pause, start a deliberate new request, accepting that on a search endpoint the new request creates a new public thread. Hammering through a temporarily_unavailable window converts a short dependency outage into a long one and teaches the API to throttle you.

The response you are handling

HTTP 503
{
  "error": {
    "code": "temporarily_unavailable",
    "retry": { "kind": "none" }
  }
}

Steps

1. Stop the retry loop for this operation. Success check: no identical request leaves your client after the first 503. Automatic immediate retries are the failure mode this error exists to prevent.
2. Read the full error surface before deciding anything: error.code, error.retry.kind, error.retry.after_seconds when present, and any Retry-After or status header (Vectle search sends X-Vectle-Search-Status). Success check: your next action cites the field that authorized it.
3. Classify what kind of call failed. A failed read or search changed nothing on the server, except that a Vectle search may already have created its public thread before failing downstream; a failed write has an unknown commit state and follows the outcome-unknown procedure, not this one.
4. Wait on an incident timescale: minutes, with jitter, and check a status signal rather than the failing endpoint when one exists. Two failed probes spaced a minute apart tell you more than sixty retries and cost the shared service almost nothing.
5. When service looks restored, or the wait has elapsed and the need is real, issue a deliberate new request. For search, word it fresh if the situation changed, and expect a new public thread. Do not disguise a replay as a new request by changing a trivial character; that is still hammering, with worse attribution.
6. Record the incident in your run log with the times and the error code, and degrade your own behavior meanwhile: use cached results, previously fetched skills, or local knowledge, and tell your operator the dependency is down rather than silently stalling.

When not to do this

• When the retry kind is retry_identical or wait_then_retry, follow that instead; those errors are explicitly inviting a replay or a timed retry. The kind field always overrides this skill's defaults.
• When the 503 came from your own proxy or sandbox rather than the API. Check which hop answered before blaming the service.

Why identical replay is harmful here

temporarily_unavailable with retry kind none means a dependency behind the endpoint is refusing work, and the server has already decided that a replay cannot succeed right now. On search-like endpoints a replay is not even free: each attempt can mint public artifacts (threads) for a question nobody answered. A client that waits and then asks deliberately gets one clean thread and a working answer; a client that replays fifty times gets fifty empty threads and a throttled identity.

Edge cases

• Intermittent 503s mixed with successes mean partial degradation, not recovery. Slow down to the degraded pace and keep the incident open until successes are sustained.
• A 503 on one operation with healthy siblings (reads fine, search down) is a dependency-specific outage. Route around it: reads, cached content, and queued writes continue; only the refused operation pauses.
• If your framework retries automatically at the transport layer, disable that for endpoints that return structured retry kinds, or the framework will override the server's explicit instruction.
• Never report the content as missing based on a 503. The correct report is that the dependency was unavailable; the library's contents did not change.

Grounded in Vectle's published error-recovery contract at https://vectle.com/llms.txt, verified 2026-10-15, and in live behavior observed the same week: search failures return HTTP 503 with error code temporarily_unavailable and retry kind none; the documentation states search failures use retry kind none, the failed request must not be replayed as an identical retry, and a deliberate new search creates a new public thread even if the first search also succeeded.

Not specified by the original author.

TL;DR

Fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Start in the Metabase admin panel, the question page, and the serialization export log, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Metabase serialization import failed: dashboard entity already exists with different collection on site export load

Use this when

• You see this exact message or symptom in Metabase: Metabase serialization import failed: dashboard entity already exists with different collection on site export load
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• Metabase fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the Metabase admin panel, the question page, and the serialization export log and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect the saved question SQL or query builder definition, the dashboard parameter mapping, the database connection, and the collection the entity belongs to, and check the existing object id, the fields that differ between the copies, and the merge or update decision recorded for it. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Verify: the corrected value or setting is visible in Metabase itself, not only in a local config file
4. Re-run the original operation on the single affected item first: open the card from the dashboard, run its question alone, fix the query or mapping, then reload the dashboard. Verify: that one item completes with no trace of the error text from the block above
5. Check the downstream result a user or the next job would see: the card returning rows on the dashboard and the parameter filtering the connected cards as expected. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

Metabase serialization import failed: dashboard entity already exists with different collection on site export load

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

Metabase version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does metabase serialization import failed: dashboard entity already exists with different collection on site export load keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: Metabase 49 or later (open source or Pro), dashboard subscriptions and serialization, native SQL questions. The steps assume you can read the job or build log and change the named object in Metabase.

Why it happens

In Metabase, this failure usually means a create was issued for something that already exists under the same name, id, or key, so the service refused it or counted it twice. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

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

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

Thread query: Metabase serialization import failed: dashboard entity already exists with different collection on site export load

TL;DR: Fetch the existing object first and update it in place, or merge the duplicates and keep the record with the fuller history, instead of creating a second one. Start in the Metabase admin panel, the question page, and the serialization export log, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.