What causes "Received an out of order chunk." in quasarframework/quasar?

Serialize large sends (await completion of one chunked message before starting the next).

Received an out of order chunk.

Error message

Received an out of order chunk.

What it means

A chunk arrived whose chunkIndex does not match the next expected index of the in-progress reassembly buffer. The bridge warns, deletes the partial chunkMap entry, and aborts the whole transfer rather than delivering a corrupt message.

Source

Thrown at app-vite/exports/bex/private/bex-bridge.js:710

      if (chunk === void 0) {
        if (packet.chunkIndex !== void 0) {
          this.warn('Received an unregistered chunk.', packet)
          return
        }

        this.chunkMap[packet.id] = {
          portName: packet.from,
          number: packet.chunksNumber,
          messageType: packet.messageType,
          messageProps: packet.messageProps,
          payload: []
        }
        return
      }

      // if we received an unexpected chunk
      if (packet.chunkIndex !== chunk.payload.length) {
        this.warn('Received an out of order chunk.', packet)

        // free up resources
        delete this.chunkMap[packet.id]
        return
      }

      chunk.payload.push(packet.payload)

      // if we received all chunks...
      if (packet.chunkIndex === chunk.number - 1) {
        delete this.chunkMap[packet.id]

        this.#onMessage({
          id: packet.id,
          from: packet.from,
          to: packet.to,
          payload: chunk.payload,
          type: chunk.messageType,

View on GitHub (pinned to 4841521b5f)

Solutions

Serialize large sends (await completion of one chunked message before starting the next).
Retry the transfer from the sender when this warning appears — the message is dropped.
Split payloads into smaller messages or reduce per-message size below chunking thresholds.
Keep the receiving end alive (avoid long async work between chunk arrivals).

Example fix

// before
bridge.send('a', bigA) // chunked
bridge.send('b', bigB) // chunked concurrently -> interleaved
// after
async function sendInOrder() {
  await bridge.send('a', bigA)
  await bridge.send('b', bigB)
}

Defensive patterns

Strategy: retry

Validate before calling

// serialize chunked sends to avoid interleaving
let sending = Promise.resolve()
function sendOrdered(event, payload) {
  sending = sending.then(() => bridge.send(event, payload))
  return sending
}

Try / catch

try {
  await bridge.send('event', largePayload)
} catch {
  // out-of-order chunk aborts the transfer; retry once
  await bridge.send('event', largePayload)
}

Prevention

Queue large sends so chunk streams never interleave.
Keep receiving contexts alive (no long blocking work between chunks).
Retry failed transfers — the receiving side drops partial data.
Split data into several smaller messages instead of one huge payload.

When it happens

Trigger: Packet reordering or loss between extension contexts (e.g. messages crossing ports while a previous transfer is still streaming); two concurrent sends interleaving chunk packets with the same id; a missed packet causing a permanent gap.

Common situations: Sending multiple large payloads rapidly in parallel over the same port; background service worker throttling delaying some packets; extremely large messages exceeding reliable transfer size.

Related errors

AI-assisted analysis of quasarframework/quasar@4841521b5f (2026-08-30). Data as JSON: /api/errors/64ebaf8f83db3021. Report an issue: GitHub.