Operation Latency

When you trigger an async mutation like refetchEngagementBulk, the resulting operation reports status: COMPLETED essentially immediately — completedAt == createdAt. But the actual upstream fetch can take tens of seconds to populate the new values into currentEngagement.

If you poll operation.status and then read currentEngagement the moment status flips to COMPLETED, you’ll often get stale values.

The practical workaround

After the operation reports COMPLETED, wait at least 60 seconds before reading the new values. Scale by roughly 10 seconds per item for larger batches, up to a few minutes total.

operation enqueued    ──► status: COMPLETED (immediate)
                             │
                             ▼  wait ≥ 60s (longer for big batches)
                             │
                             ▼
read currentEngagement   ──► fresh values

Why this happens

COMPLETED on the operation object means “Archive successfully enqueued the upstream platform fetch,” not “Archive received fresh data from Instagram / TikTok / YouTube.” Those upstream calls happen async on workers that the operation handle isn’t aware of.

A future iteration of the API will likely distinguish “queued” from “data settled” more clearly. Until then, treat COMPLETED as the start of your wait, not the end.

Affected surfaces

• refetchEngagementBulk — the main one.
• Any other mutation that returns an operationId for async work.

currentEngagement reads via the items query are not affected by this delay — they always return the latest snapshot Archive has, regardless of any in-flight operations. The delay only matters when you’re trying to read the values from a fresh refresh you just triggered.