What causes "Received an unregistered chunk." in quasarframework/quasar?

Re-send the whole message from the sender when this warning appears (the transfer is unrecoverable).

Received an unregistered chunk.

Error message

Received an unregistered chunk.

What it means

The bridge received a chunk-type packet whose id is not in chunkMap and which carries a chunkIndex, meaning it's a continuation of a chunked message whose first packet was never registered (or was already consumed/deleted). The bridge warns and drops the packet.

Source

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

    if (packet.type === 'full') {
      this.#onMessage({
        id: packet.id,
        from: packet.from,
        to: packet.to,
        payload: packet.payload,
        type: packet.messageType,
        props: packet.messageProps
      })
      return
    }

    if (packet.type === 'chunk') {
      const chunk = this.chunkMap[packet.id]

      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

View on GitHub (pinned to 4841521b5f)

Solutions

Re-send the whole message from the sender when this warning appears (the transfer is unrecoverable).
Keep the receiving context alive during large transfers (avoid service-worker suspension, keep ports active).
Reduce payload size or raise chunk size configuration so fewer packets are exchanged.
Ensure unique message ids per transfer to avoid collisions.

Example fix

// before
bridge.send('big-event', hugeArrayBuffer) // transfer interrupted, chunks orphaned
// after
try {
  bridge.send('big-event', hugeArrayBuffer)
} catch {
  bridge.send('big-event', hugeArrayBuffer) // resend restores a fresh chunk id
}

Defensive patterns

Strategy: retry

Validate before calling

// keep payload modest and receiver alive during transfer
const MAX_SAFE_SIZE = 32 * 1024 * 1024
if (payload.byteLength > MAX_SAFE_SIZE) {
  throw new Error('Payload too large for reliable bridge transfer')
}

Type guard

const isTransferable = (p) => p instanceof ArrayBuffer || typeof p === 'string' || (p && typeof p === 'object')

Try / catch

try {
  bridge.send('big-event', payload)
} catch (err) {
  // chunk state is lost; resend from scratch
  bridge.send('big-event', payload)
}

Prevention

Avoid sending multiple large chunked messages concurrently.
Prevent service worker suspension during transfers.
Reduce payload sizes to minimize chunking.

When it happens

Trigger: An intermediate chunk arrives for a transfer that was already finalized/aborted (e.g. after the out-of-order cleanup deleted the entry), or packets were dropped/reordered across ports; duplicate sends sharing the same chunk id.

Common situations: Very large payloads being chunked while the receiving side restarted (service worker wake-up) losing chunkMap state; slow receivers hitting the out-of-order path first, making subsequent chunks 'unregistered'.

Related errors

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