You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
internal/cli/errors.go and the CLI commands wrap errors with typed sentinels (errx) and add context, which matches the “wrap at
module boundaries” idea. But those errors don’t capture stack traces, timestamps, or host info, and user output is just the raw
error message (no friendly one-liner or correlation ID).
The operator layer uses the same errx helpers (internal/operator/errors.go, internal/operator/controller.go) to add context, but
likewise lacks stack traces/timestamps and doesn’t generate user-facing IDs.
Other packages (e.g., pkg/metadata/loader.go) still return plain fmt.Errorf values with %w; they aren’t wrapped into a module-
specific type or enriched, so boundary enforcement isn’t consistent.
Top-level handling (cmd/mcp-runtime/main.go) just prints err.Error() to stderr; it doesn’t distinguish well-formed vs malformed
errors, doesn’t attach a log ID, and doesn’t map messages to friendly user text.
Nowhere are correlation IDs, stack traces, or UTC instantiation times recorded or surfaced, so postmortems and user bug reports
can’t link to detailed logs.
module boundaries” idea. But those errors don’t capture stack traces, timestamps, or host info, and user output is just the raw
error message (no friendly one-liner or correlation ID).
likewise lacks stack traces/timestamps and doesn’t generate user-facing IDs.
specific type or enriched, so boundary enforcement isn’t consistent.
errors, doesn’t attach a log ID, and doesn’t map messages to friendly user text.
can’t link to detailed logs.