siyuan-note/siyuan · error
panic during siyuan.client.event
Error message
panic during siyuan.client.event: %v
What it means
The siyuan.client.event stream runs its connection loop in a background Go goroutine. Any panic in that loop is recovered, the stream is closed, and the panic is converted to this error and surfaced to the plugin's JS error callback. It signals an internal defect or unexpected runtime condition in the event-stream machinery, not a normal plugin API error.
Solutions
- Inspect the wrapped %v value in the message to identify the underlying panic and report it upstream with a reproduction
- Minimize the event handler and reconnect to isolate which topic/event triggers it
- Handle the stream error callback and reconnect defensively so a dropped stream does not break the plugin
- Update to the latest kernel version in case the panic is an already-fixed internal bug
Example fix
const es = siyuan.client.event('/events/push',
(ev) => { try { handle(ev); } catch (e) { console.error(e); } },
(err) => { console.error('event stream failed:', err); scheduleReconnect(); }); Defensive patterns
Strategy: try-catch
Validate before calling
null
Type guard
null
Try / catch
const es = siyuan.client.event(streamPath, onEvent, (err) => {
if (String(err.message).startsWith('panic during siyuan.client.event')) {
console.error('Kernel event stream panicked:', err.message);
setTimeout(reconnect, backoff++ * 1000);
}
}); Prevention
- Keep event handlers defensive (try/catch inside handlers) so failures are contained
- Implement reconnect with backoff on stream errors
- Keep the kernel updated; report panics with reproduction steps
When it happens
Trigger: A panic inside the event-stream read/dispatch goroutine: nil dereference while processing a pushed event, unexpected close/reconnect ordering, or abnormal termination of the underlying HTTP stream.
Common situations: Kernel bugs during event dispatch; races when the plugin closes the stream while events are in flight; stress-testing event-driven plugins.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
AI-assisted analysis of siyuan-note/siyuan@9f775e8a12 (2026-09-19).
Data as JSON: /api/errors/9097a0e1a81d2988.
Report an issue: GitHub.
Appendix: source
Thrown at kernel/plugin/api_client.go:697
lo.Must0(esObj.Set("readyState", rt.ToValue(readyState.Load())))
lo.Must0(esObj.Set("url", rt.ToValue(path)))
lo.Must0(esObj.Set("onopen", goja.Null()))
lo.Must0(esObj.Set("onmessage", goja.Null()))
lo.Must0(esObj.Set("onclose", goja.Null()))
lo.Must0(esObj.Set("onerror", goja.Null()))
lo.Must0(esObj.Set("close", es_close))
lo.Must0(ObjectSeal(rt, esObj))
setReadyState(EventSourceConnecting)
go func() {
var err error
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("panic during siyuan.client.event: %v", r)
}
doClose()
p.worker.Run(func(rt *goja.Runtime) (_ any, _ error) {
if err != nil && !errors.Is(err, context.Canceled) {
event := rt.NewObject()
event.Set("type", rt.ToValue("error"))
event.Set("error", rt.NewGoError(err))
invokeEsHook("onerror", event)
}
if EventSourceState(readyState.Load()) != EventSourceClosed {
setReadyState(EventSourceClosed)
}
return
}, nil)
}()
View on GitHub (pinned to 9f775e8a12)