Relay v2 parser output via otel log format for output parity

[aiguofer]

Stacked on #16281 (rebrand-fusion-to-v2-parser). Review that one first; this PR's diff is only the commits stacked on top of it.

Previous behavior

--use-v2-parser shells out to the v2 (Fusion) binary and relays its log lines. The relay invoked it with --log-format json and forwarded every line as a flat Note event, keeping only the message text and the level. Consequences:

• Duplicate banners and span noise. The json-compat layer renders events that v2's own TUI layer has no arm for — per-node span starts/ends, run banners — so v1 printed lines a user running v2 directly would never see. The two layers have independently drifted: v2's TUI applies several stateful gates before printing a node-processed line that json-compat applies none of.
• Error/warning codes lost. v2 composes [Generic (dbt1000)]-style prefixes at render time; the json wire carries the code as a separate field, which the relay discarded.
• No color. json-compat deliberately strips ANSI, so all relayed output was plain regardless of --use-colors.
• Latent --warn-error abort. Unrecognized lines were relayed at WARN. Under --warn-error, WARN events are promoted to a raised EventCompilationError matched by event class name, so a single stray line of v2 stderr could abort an otherwise-successful parse.

New behavior

Invoke with --log-format otel and parse the JSONL envelope (SpanStart / SpanEnd / LogRecord).

Spans are dropped, with one deliberate exception (below). This is the load-bearing change: in the otel schema only LogRecord has a body field — spans structurally do not — so consuming just the message-shaped records both fixes the body problem and removes the span-derived noise with no hand-maintained denylist. v1 also stops being coupled to v2's span-visibility logic, which is where the layer drift lives.

Of the remaining log records, an allowlist is relayed:

event	handling
LogMessage, UserLogMessage	relay body, with the v2 error/warning code composed back into the message text ([Generic (dbt1000)]: ...)
ProgressMessage	rendered v1-side, reproducing v2's {action} {target} ({description}) column formatting from the record's attributes

Severity comes from the OTLP severity_number, mapped onto EventLevel by band. WARN/ERROR styling uses v1's own dbt_common.ui tag helpers rather than trying to be byte-identical to v2 — the output looks native to v1 while carrying the same information, and it stays plain text that platform log ingestion parses unchanged.

Unparseable or unrecognized lines now relay at INFO, fixing the --warn-error abort above.

The end-of-run status line

v2's Finished 'parse' with 1 warning for target 'default' [1.2s] has no LogRecord: it exists only as a console-formatter rendering of the Invocation span's end attributes. Dropping every span would have silently deleted it, so the Invocation span end is the one span record the relay reads rather than discards, and the line is synthesized v1-side from its attributes.

The counts come from v2's own metric aggregator (metrics.total_warnings / total_errors), so they stay correct even for warnings whose LogRecords this relay filtered out. Mirrored from v2's formatters/invocation.rs: the success/warning/error phrasing and coloring (both counts red once any error is present), singular/plural labels, the for target '...' clause, the duration tiers from formatters/duration.rs, and the RESULT_LINE_OPT_OUT_COMMANDS set — so the relay withholds the line on exactly the commands (man, login) where v2 itself prints none.

Two wire details worth noting, both covered by tests: pbjson renders proto uint64 as a JSON string, and it omits optional fields entirely when unset — so both "12" and a missing key have to be handled.

The subprocess no longer writes its own dbt.log

--log-level-file off is now forwarded too. v2 defaults its file log to {--project-dir}/logs/dbt.log, and _build_argv forwards --project-dir but not --log-path — so on any run that doesn't redirect the log path (a plain local CLI run), that resolves to the same file dbt-core writes its own file log to. Both processes were appending the same relayed events to it, with no shared locking, producing a logs/dbt.log with every parser line doubled and the two writers' formats interleaved.

Nothing is lost by turning it off: everything the subprocess emits already reaches dbt-core over stdout and lands in dbt.log through dbt-core's own logger.

Note this is fixed explicitly rather than relying on the format switch. The otel format happens to install no file-log layer (config.rs, LogFormat::Otel => None), so the double-write would have disappeared on its own — but incidentally, and it would come back if a file renderer is added for otel or if a run passes --log-format-file. --log-level-file off short-circuits before the writer is even constructed, so no logs/ dir or empty file is created either.

This is unrelated to the duplicate-log display in Studio/IDE. That is an ide-server realtime-buffer-vs-finalized-artifact overlap, fixed separately by dbt-labs/ide-server#1488; platform redirects dbt-core's log path per task and never ingests the subprocess's file, so this change neither causes nor fixes that symptom.

Notes

• Relayed message text is not scrubbed for credential-bearing URLs on either wire. The cloud-cli path gets this from fusion-client-python's scrub_message(); a v1 relay has no equivalent. Not a regression introduced here, and I have not confirmed such URLs can actually appear in relayed text, but it is worth a second opinion before this ships widely.

Example outputs

CLI:

Studio:

[Copilot]

🟡 Changes recommended

Record validation/fallback and coded UserLogMessage handling need correction.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Updates v2 parser output relaying from JSON compatibility logs to OTEL JSONL for cleaner, richer parity.

Changes:

• Filters spans and relays supported log records.
• Preserves severity, codes, progress formatting, and native styling.
• Adds unit coverage and a changelog entry.

File summaries

File	Reviewed changes
tests/unit/parser/test_v2.py	Tests OTEL filtering, formatting, severity, and fallback behavior.
core/dbt/parser/v2.py	Implements OTEL parsing and event relaying.
.changes/unreleased/Fixes-20260911-155947.yaml	Documents the fix.

Review details

Suppressed comments (1)

core/dbt/parser/v2.py:547

• The stated relay behavior groups LogMessage and UserLogMessage together for restoring the v2 code/code_name prefix, but this condition only applies _prefix_log_message_code to LogMessage. Any coded UserLogMessage will therefore lose its [Name (dbt####)] text. Apply the same prefix helper to both message event types (it is a no-op when the attributes have no code).

                if event_type == _EVENT_TYPE_LOG_MESSAGE:

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mishamsk]

lgtm. see 2 nits

[mishamsk]

second time as charm!