moeru-ai/airi · warning

[context-bridge] spark:notify handling failed; using fallbac

Error message

[context-bridge] spark:notify handling failed; using fallback

What it means

characterOrchestratorStore.handleSparkNotifyWithReaction threw while processing a spark:notify event — typically an LLM provider call, tool execution, or reaction pipeline failure. The bridge swallows the error and returns options.fallbackResponseText, so the user still receives a reply instead of a dropped notification. Only the richer reaction is lost.

Source

Thrown at packages/stage-ui/src/stores/mods/api/context-bridge.ts:241

        payload: options.payload,
        ttlMs: options.ttlMs,
        requiresAck: options.requiresAck,
        destinations: options.destinations?.length ? options.destinations : ['character'],
        metadata: options.metadata,
      },
    }

    try {
      return await characterOrchestratorStore.handleSparkNotifyWithReaction(event, {
        fallbackText: options.fallbackResponseText,
        forceResponse: options.forceResponse,
        forceTextResponse: options.forceTextResponse,
        forceSparkCommandResponse: options.forceSparkCommandResponse,
        messageOverride: options.messageOverride,
      })
    }
    catch (error) {
      console.warn('[context-bridge] spark:notify handling failed; using fallback', error)
      return options.fallbackResponseText
    }
  }

  function setSparkNotifyHostRole(role: 'main' | 'client') {
    sparkNotifyHostRole.value = role
  }

  async function dispatchSparkNotifyReaction(options: SparkNotifyReactionOptions) {
    if (sparkNotifyHostRole.value === 'main') {
      return await handleSparkNotifyReactionLocal(options)
    }

    const requestId = nanoid()
    return await new Promise<string>((resolve) => {
      const timeout = setTimeout(() => {
        sparkNotifyBridgeWaiters.delete(requestId)
        resolve(options.fallbackResponseText)

View on GitHub (pinned to 677329427f)

Solutions

  1. Check provider credentials/quota in settings — most failures originate at the LLM provider call
  2. Inspect the logged error object for HTTP status (401/429/5xx) to pick the fix
  3. Keep a meaningful fallbackResponseText so users are never left without a reply
  4. If failures repeat for one character, review its orchestrator module configuration
Defensive patterns

Strategy: fallback

Try / catch

try {
  return await characterOrchestratorStore.handleSparkNotifyWithReaction(event, { fallbackText: options.fallbackResponseText, forceResponse: options.forceResponse, /* ... */ })
}
catch (error) {
  console.warn('[context-bridge] spark:notify handling failed; using fallback', error)
  return options.fallbackResponseText // conversation continues with a generic reply
}

Prevention

When it happens

Trigger: LLM provider HTTP failure (rate limit, invalid key, quota) inside the reaction pipeline; a tool executed during the reaction throwing; provider response shape changing after a runtime update and failing validation.

Common situations: Expired or invalid provider API key; provider rate limiting during bursts of spark notifications; orchestrator module misconfigured after an update.

Related errors


AI-assisted analysis of moeru-ai/airi@677329427f (2026-08-18). Data as JSON: /api/errors/576ca61f9c14019e. Report an issue: GitHub.