What causes "Failed to send a chunk-abort message to "${to}"." in quasarframework/quasar?

Fix the root cause of the original send failure (check the accompanying error in the warning payload)

Failed to send a chunk-abort message to "${to}".

Error message

Failed to send a chunk-abort message to "${to}".

What it means

When a chunked message transfer fails mid-way, #sendMessage attempts to send a 'chunk-abort' packet so the receiver frees its chunkMap entry. This warning is logged when even that abort packet could not be delivered (port gone, receiver unregistered). The original error is still re-thrown to the caller; this warning only signals the receiver may keep a stale partial-chunk entry.

Source

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

          id,
          from: this.portName,
          to,
          type: 'chunk',
          payload: payload[i],
          chunkIndex: i
        })
      )
    }

    return promise.catch(err => {
      // oxlint-disable-next-line promise/no-nesting
      this.#sendPacket({
        id,
        from: this.portName,
        to,
        type: 'chunk-abort'
      }).catch(sendPacketErr => {
        this.warn(
          `Failed to send a chunk-abort message to "${to}".`,
          sendPacketErr
        )
      })

      throw err
    })
  }

  #onMessage(message) {
    if (message.type === 'event-response') {
      const target = this.messageMap[message.id]

      if (target === void 0) {
        if (message.props.quiet !== true) {
          this.warn(
            `Received a response for an unknown message id: "${message.id}".`,
            message

View on GitHub (pinned to 4841521b5f)

Solutions

Fix the root cause of the original send failure (check the accompanying error in the warning payload)
Re-register the receiver port (ensure the content script/UI reconnected to background) before retrying
Reduce payload size or flatten the Array to avoid chunking if transfers are fragile
Retry the whole message after confirming both contexts are alive; stale chunkMap entries are cleaned on 'chunk-abort' or out-of-order chunks

Example fix

// before: send a huge array over a possibly-stale port
await bridge.send('bulk', hugeArray)
// after: verify the connection first, retry on failure
try {
  await bridge.send('bulk', hugeArray)
} catch (err) {
  await reconnectPort() // re-establish, then retry once
  await bridge.send('bulk', hugeArray)
}

Defensive patterns

Strategy: retry

Validate before calling

// ensure the receiver port is alive before big transfers
if (!navigator.serviceWorker.controller ||
    backgroundPortDisconnected) {
  await reconnectBackgroundPort()
}

Try / catch

try {
  await bridge.send('bulk', hugeArray)
} catch (err) {
  // chunk-abort delivery may also have failed; reconnect and retry once
  await reconnectPort()
  await bridge.send('bulk', hugeArray)
}

Prevention

Re-register ports after service worker/content script restarts before sending
Keep chunked payloads modest in size; avoid transfers that outlive tab lifetimes
Listen for port.ondisconnect and re-handshake before further sends
Treat any send failure as a full-transfer failure and resend from scratch

When it happens

Trigger: A multi-chunk send (Array payload) fails partway (a chunk postMessage throws or a later sendPacket rejects) AND the follow-up chunk-abort #sendPacket rejects — e.g. the target port was disconnected or the receiver's port name is no longer in portList.

Common situations: Receiver tab/service worker suspended or reloaded mid-transfer while sending a large Array payload through the bridge; message addressed to a port that disconnected during transfer.

Related errors

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