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
- Check provider credentials/quota in settings — most failures originate at the LLM provider call
- Inspect the logged error object for HTTP status (401/429/5xx) to pick the fix
- Keep a meaningful fallbackResponseText so users are never left without a reply
- 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
- Keep provider credentials valid; most spark:notify failures start at the LLM provider call
- Make the reaction pipeline return typed errors instead of throwing raw
- Always supply a non-empty fallbackResponseText
- Log the provider status separately from the generic warn for faster triage
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
- Spark notify ignored: missing active provider or model
- [Whisper Worker] fp16 encoder failed, falling back to fp32:
- Dropped spark:notify after max attempts:
- Failed to handle spark:notify event:
- Failed to handle spark:emit event:
AI-assisted analysis of moeru-ai/airi@677329427f (2026-08-18).
Data as JSON: /api/errors/576ca61f9c14019e.
Report an issue: GitHub.