quasarframework/quasar · warning

Received an unknown message type: "${packet.type}".

Error message

Received an unknown message type: "${packet.type}".

What it means

The BEX bridge's #onPacket handler processes low-level packets between extension contexts (background, content scripts, UI). After checking 'chunk' and 'chunk-abort' types, any other packet.type it doesn't recognize triggers this warning. It means a packet arrived whose type is neither 'full', 'chunk' nor 'chunk-abort' — almost always a version mismatch between bridge copies or corrupted/malicious postMessage traffic.

Source

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

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

      return
    }

    if (packet.type === 'chunk-abort') {
      delete this.chunkMap[packet.id]
      return
    }

    this.warn(`Received an unknown message type: "${packet.type}".`)
  }

  #sendPacket(packet) {
    this.log(
      packet.from === this.portName
        ? `Sending message of type "${packet.type}" to "${packet.to}".`
        : `Forwarding message of type "${packet.type}" from "${packet.from}" to "${packet.to}".`,
      packet
    )

    const port =
      this.#type === 'background'
        ? this.portMap[packet.to]
        : this.portMap.background

    if (!this.portList.includes(packet.to)) {
      return Promise.reject(
        `Tried to send message of type "${packet.type}" to "${packet.to}" but there is no such port registered`

View on GitHub (pinned to 4841521b5f)

Solutions

1. Reload/rebuild all extension contexts (chrome://extensions -> reload) so every script runs the same bridge version
2. Check that no external script posts arbitrary messages on the window/port the bridge listens to; filter by event source or use a dedicated port
3. Log the full packet (the warning context) and confirm the 'type' field value; fix the sender's type spelling
4. If you own both sides, align packet.type strings with the bridge protocol ('full', 'chunk', 'chunk-abort')

Example fix

// before (sender, custom type)
port.postMessage({ type: 'my-event', payload })
// after: send through the bridge API so it wraps in a known packet type
bridge.send('my-event', payload)

// before wiring a raw port listener, validate packets yourself
const KNOWN = new Set(['full', 'chunk', 'chunk-abort'])
window.addEventListener('message', ev => {
  const p = ev.data
  if (p && typeof p.type === 'string' && KNOWN.has(p.type)) bridge.handle(p)
  else console.warn('ignoring foreign packet', p)
})

const isBridgePacket = p =>
  p !== null && typeof p === 'object' &&
  ['full', 'chunk', 'chunk-abort'].includes(p.type) &&
  typeof p.from === 'string' && typeof p.to === 'string'

When it happens

Trigger: A packet is posted to this port whose type property is not 'full', 'chunk' or 'chunk-abort' (e.g. an external script posting raw messages on the same window/port, or two bridge versions in different contexts disagreeing on the protocol).

Common situations: Mixed @quasar/app-vite versions: an extension rebuilt with a newer bridge talking to a stale background/content script that wasn't reloaded; a website script or another extension injecting messages into the content-script window where the bridge listens; hand-crafted test messages with a typo'd type.

Related errors

• Received a message with unknown type: "${message.type}".
• Failed to send a chunk-abort message to "${to}".
• Received a response for an unknown message id: "${message.id
• Failed to reconnect to the background script.
• Failed to inform "${portName}" about the port list.

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