siyuan-note/siyuan · error

failed to enable extend modules: %v

Error message

failed to enable extend modules: %v

What it means

A recovered panic from EnableExtendModules, which registers require/console/url/buffer modules on the plugin's goja runtime. Any panic during registry.Enable, console registration, or url/buffer Enable is caught by the deferred recover and surfaced as this wrapped error during plugin load.

Source

Thrown at kernel/plugin/sandbox.go:79

type FunctionResult[T any] struct {
	Value T
	Error error
}

type CallResult FunctionResult[goja.Value]

func (r *CallResult) TaskResult() *TaskResult {
	if r.Error != nil {
		return &TaskResult{err: r.Error}
	}
	return &TaskResult{value: r.Value.Export()}
}

// EnableExtendModules registers extended modules (e.g. url, buffer) to the plugin's goja runtime.
func EnableExtendModules(p *KernelPlugin, rt *goja.Runtime) (err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("failed to enable extend modules: %v", r)
		}
	}()

	registry := require.NewRegistry()

	registry.Enable(rt)
	registry.RegisterNativeModule(
		console.ModuleName,
		console.RequireWithPrinter(&Printer{name: p.Name}),
	)

	url.Enable(rt)
	buffer.Enable(rt)
	console.Enable(rt)
	return
}

// EnableSiyuanModule injects all siyuan.* APIs into the plugin's goja global context.

View on GitHub (pinned to 251596fc0d)

Solutions

  1. Check the kernel log for the underlying panic value (the 'failed to enable extend modules: <panic>' line).
  2. Reinstall/update the plugin and the kernel to matching versions.
  3. Disable other plugins to rule out a global-state collision, then re-enable one at a time.
  4. Report the panic detail to the issue tracker if it persists on a clean profile.
Defensive patterns

Strategy: try-catch

Try / catch

// load-time; cannot retry meaningfully from plugin JS
// capture in the plugin loader and report
catchLoadError(e) { if (/enable extend modules/.test(String(e))) report(e); }

Prevention

When it happens

Trigger: A plugin load fails because a module registration panicked, e.g. runtime already had a conflicting require registry, a native module returned an error inside goja, or a corrupt plugin context.

Common situations: Seen at plugin activation time. Usually indicates a kernel/plugin compatibility mismatch or a double-initialization of the same runtime.

Related errors


AI-assisted analysis of siyuan-note/siyuan@251596fc0d (2026-08-12). Data as JSON: /api/errors/5f80bb8b51c4d48d. Report an issue: GitHub.