Skip to main content

conflict

HTTP 409 · code: "conflict" · type: https://docs.formfeed.dev/errors/conflict

The request conflicts with what is stored now, so nothing was changed. detail says which conflict it is.

Example​

{
  "type": "https://docs.formfeed.dev/errors/conflict",
  "title": "Conflict",
  "status": 409,
  "detail": "The template changed since the base version; pull first or pass force",
  "code": "conflict",
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Common causes​

  • POST /templates with a slug that already exists in the workspace (A template with this slug exists in the workspace).
  • POST /templates/{id}/versions with a base_checksum that no longer matches the latest version, because someone saved or published in between. formfeed templates push sends it for you, from the last pull.
  • PUT /partials/{name} with a base_version that is no longer the shared partial's version. The problem then carries the stored partial as current (or null when it was deleted). See Brand and partials.
  • Redelivering copies to the workspace's own bucket while the storage connection is paused; paused_reason says why (plan when the plan no longer includes it).
  • A formfeed login device code that was already used.
  • POST /webhooks/{id}/test for a disabled endpoint, which receives nothing (The endpoint is disabled; set enabled to true before sending a test).

How to fix it​

  • For a slug: choose another one, or update the existing template.
  • For a version: fetch the latest version, merge your change into it, and send its checksum as base_checksum. formfeed templates push --force overrides the check when you are sure.
  • For a shared partial: read it again (formfeed partials pull <name>), merge, and send its new version as base_version, or push with --force.
  • For a paused connection: fix the credentials and test the connection again in the app, or move to a plan with bring your own storage.
  • For a device code: start formfeed login again.
  • For a webhook test: switch the endpoint on (PUT /webhooks/{id} with "enabled": true, or its switch on the Webhooks page), then send the test again.

Retry?​

No. The same request gets the same answer. Change it as above, then send it again with a new Idempotency-Key or without one: a 4xx answer is stored under its key for 24 hours, so the old key returns this problem again. See retrying.