Skip to content

fix(observability): name the module on the chain-request lines - #376

Merged
mfw78 merged 1 commit into
mainfrom
fix/name-the-module-on-chain-lines
Aug 26, 2026
Merged

mfw78 merged 1 commit into
mainfrom
fix/name-the-module-on-chain-lines

Conversation

@mfw78

@mfw78 mfw78 commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

What

Four tracing sites in the chain host call now name the module: the response-cap refusal, the denied-method refusal, and the two chain::request lines below the default level. check_response_cap takes the module rather than deriving it, since it is a free function.

The runbook query in docs/production.md is fixed. It filtered on .fields.module, but crates/nexum-launch/src/lib.rs sets flatten_event(true), so event fields sit at the top level and there is no .fields object. The published command matched nothing on every line.

Why

Two of the four print at the default log_level = "info" and are the only lines that answer "which module". nexum_runtime_chain_request_total carries chain_id, method and outcome but no module label, and docs/production.md sells method="<denied>" as the signal that a module is reaching outside the read surface. Neither the counter nor the log line named which one, so that alert was undiagnosable from telemetry alone. Same hole on nexum_runtime_chain_response_capped_total.

The runbook fix is unrelated and pre-existing. It is here because it is one line and was found in the same review.

Why not a span

#373 proposed a dispatch span carrying the module, and is closed unmerged. Four lenses agreed it did not earn the change: every tracing site in supervisor/dispatch.rs already carries module, as do the guest-mirror sites, the http gate and the store error path, so the span would have duplicated a field already on the line. It carried no span id, so it did not distinguish two concurrent dispatches of one module either. These four sites were its entire verified benefit.

Passing the field also covers a case the span could not: instantiate_module runs guest init inside no span, and a host call made from init reaches these same seams.

Testing

cargo nextest run -p nexum-runtime-wasm --all-features --locked: 28 passed. Clippy over the crate with -D warnings clean, cargo fmt --all --check clean, content-lint.sh ok, just build green.

AI Assistance

Review by four claude-opus-5 lenses; fix and PR description by claude-opus-5.

Four tracing sites in the chain host call named no module, so the two
that print at the default level said a read was denied or a response was
capped without saying whose. nexum_runtime_chain_request_total carries no
module label either, which left the denied-read-surface signal
docs/production.md sells as an alert undiagnosable from telemetry alone.

check_response_cap gains the module rather than reading it from a span:
the guest init path calls into the same host seams and runs inside no
span at all.

Also fix the runbook query, which filtered on .fields.module while the
JSON layer sets flatten_event, so event fields sit at the top level and
there is no .fields object. It matched nothing on every line.

AI Assistance: claude-opus-5 used for the fix, after a four-lens review
of the span approach it replaces.
@mfw78
mfw78 merged commit a2b3e83 into main Aug 26, 2026
7 checks passed
@mfw78
mfw78 deleted the fix/name-the-module-on-chain-lines branch August 26, 2026 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant