Teams error 412 PreconditionFailed: PreconditionFailed - concurrent operations on one conversation

The status table documents PreconditionFailed as "A precondition failed on one of our dependencies due to multiple concurrent operations on the same conversation," with retry Yes and the strategy "Retry with exponential backoff." In other words: two or more of your requests raced on the same conversation state inside Microsoft's storage layer, one of them lost, and losing is recoverable.

Bots see this when they parallelize sends, updates, or deletes into the same thread - a fan-out worker pool that happens to schedule two operations on one conversation simultaneously, or a card update fired while the previous update is still in flight. The rate-limit guide reinforces the handling: "In addition to retrying error code 429, error codes 412, 502, and 504 must also be retried." A single serialized queue per conversation makes the error effectively disappear.

Unlike 429 there is no Retry-After header and no budget being enforced; this is optimistic concurrency losing a race, so the retry can be quick - the documented exponential backoff exists to stop two colliding writers from colliding again on the same schedule.

{
  "error": {
    "code": "PreconditionFailed",
    "message": "Precondition failed, please try again."
  }
}

Key your send pipeline by conversation ID so concurrency happens across conversations, never within one. This also keeps you inside the per-thread rate limits, whose windows are tight enough that intra-conversation parallelism buys nothing anyway. Wrap Connector calls in the SDK's transient-fault retry policy once, centrally, rather than per call site.