ActivityPub Delivery Queue#

Misskey uses BullMQ (backed by Redis) for all asynchronous job processing. ActivityPub federation delivery runs through two key independent queues:

• deliver queue — sends outbound ActivityPub activities (notes, deletes, follows, etc.) to remote instance inboxes via signed HTTP POST.
• db queue — handles database-heavy background work including account deletion, data exports/imports, and more.

These queues run concurrently with no ordering guarantees between them, which is the root of several known race conditions.

Queue Configuration#

Workers are initialized in QueueProcessorService.

Both deliver and inbox workers use a custom exponential backoff strategy (httpRelatedBackoff) with a 1-minute base delay and an 8-hour maximum 3.

Deliver jobs are enqueued via QueueService.deliver() (single) or QueueService.deliverMany() (bulk). Each job is configured with up to 12 retry attempts (configurable via deliverJobMaxAttempts) and removed from the queue after 7 days or 30 completed / 100 failed jobs 4.

Deliver Job Processing#

DeliverProcessorService.process() handles each outbound delivery:

1. Pre-flight checks — skips delivery if the target URL is federation-blocked or the host is suspended 5.
2. HTTP POST — calls ApRequestService.signedPost() with the actor's keypair 6.
3. Success path — updates isNotResponding state, triggers metadata refresh, and updates charts 7.
4. Failure path (HTTP errors) — marks the host as isNotResponding. After 7 consecutive days of failures, auto-suspends the instance. For 4xx non-retryable errors, throws Bull.UnrecoverableError to permanently discard the job; HTTP 410 on a shared inbox triggers goneSuspended state 8. 5xx errors and network failures re-throw and trigger BullMQ's backoff retry 9.

Known Issue: Race Condition on Account Deletion#

Status: Open bug as of 2026.6.0 10

Root Cause#

When DeleteAccountService.deleteAccount() is called for a local user, it:

1. Enqueues ActivityPub Delete delivery jobs for all known shared inboxes (into the deliver queue) 11.
2. Immediately after, enqueues a deleteAccount job (into the db queue) 12.

Because these are independent queues, the db queue's DeleteAccountProcessorService can physically delete the user row — cascade-deleting MiUserKeypair — before the deliver queue has finished sending all the Delete activities 13.

When any still-pending deliver job executes after the user row is gone, UserKeypairService.getUserKeypair() calls findOneByOrFail() 14, which throws EntityNotFoundError.

Why Jobs Accumulate#

The catch block in DeliverProcessorService only handles StatusError (HTTP errors) and network errors 15. An EntityNotFoundError from the database is not caught as unrecoverable — it falls through as a generic error, causing BullMQ to retry the job with the full exponential backoff (up to 8 hours), repeating until max attempts are exhausted. The result is a growing backlog of stuck jobs in the Delay state of the deliver queue.

Observed Symptom#

Could not find any entity of type "MiUserKeypair" matching: { "userId": "..." }

Jobs accumulate in the deliver queue's Delay section and do not drain 10.

Proposed Mitigations#

Three approaches are discussed in issue #17760:

Key Source Files#