quasarframework/quasar · warning

Received a response for an unknown message id: "${message.id

Error message

Received a response for an unknown message id: "${message.id}".

What it means

An 'event-response' packet arrived but no pending promise in messageMap matches its id — the request it answers was already resolved/rejected (e.g. by timeout), the receiver restarted and lost its messageMap, or the response is a duplicate. Suppressed when the message was sent with props.quiet === true. Otherwise logged as a warning; the response is dropped.

Source

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

        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
          )
        }
        return
      }

      if (message.props.error !== void 0) {
        target.reject(message.props.error)
      } else {
        target.resolve(message.payload)
      }

      return
    }

    if (message.type === 'event-send') {
      this.#triggerMessageEvent({

View on GitHub (pinned to 4841521b5f)

Solutions

1. Ignore if benign (late response after timeout) — it's a warning, not a failure
2. Increase the caller-side timeout so slow handlers can answer while the promise is still pending
3. Ensure the responding side re-syncs state after reload instead of replying to pre-reload ids
4. Set props.quiet = true when firing responses whose requester may legitimately be gone

Example fix

// before: fixed short timeout discards late but valid responses
const res = await bridge.send('query', data) // times out at 1s
// after: tolerate slow handlers (raise timeout) or mark quiet on responder side
setTimeout(() => controller.abort(), 10_000)

try {
  const res = await bridge.send('query', data)
} catch (err) {
  // includes timeouts: late responses later surface as
  // "unknown message id" warnings and can be safely ignored
  console.error('send failed', err)
}

When it happens

Trigger: A bridge.send() promise already settled (timeout/caller gave up) and the late response arrives; the responding context answers a message id unknown locally (state lost after reload); duplicate responses sent for the same id.

Common situations: Slow handler responding after the requester's timeout; background service worker or content script reloaded mid-request; sending the same id twice from a custom sender.

Related errors

• Received an unknown message type: "${packet.type}".
• Failed to send a chunk-abort message to "${to}".
• Received a message with unknown type: "${message.type}".
• 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/bcdf67de48aa435a. Report an issue: GitHub.