Add 'Debugging from the UI' section with parallel-worker URLs and known limitations

[samgutentag]

Reopens the work from #58, which was merged then reverted on 2026-06-01 (it was not ready to merge). Content is unchanged from the original branch; needs content verification against source before re-merging. Reverted merge commit removed from main.

[samgutentag]

Code verification (2026-06-01): 1 confirmed / 1 contradicted / 1 ambiguous / 4 unverifiable

Claim	Verdict	Source
trunk-analytics-cli prints a "Bundle Upload ID" to the job log	confirmed	cli/src/upload_command.rs:645
rspec_trunk_flaky_tests gem "is being extended" to extract the full set of exceptions; "until that ships," check CI logs	contradicted	rspec-trunk-flaky-tests/lib/trunk_spec_helper.rb:263-280
Failure detail view surfaces only one of the captured exceptions on a MultipleExceptionError	ambiguous	trunk_spec_helper.rb:263-280
Bundle Upload ID does not map to a URL / has no dashboard search field	unverifiable	absence claim; not provable from source
Go subtests reported as 0ms duration confuse the AI failure analysis	unverifiable	no Trunk source handles per-subtest duration
Uploads can take up to 10 minutes to populate run data	unverifiable	no ingestion-latency constant in source
CI per-worker URL env vars (CIRCLE_BUILD_URL, BUILDKITE_BUILD_URL, CI_JOB_URL, GitHub Actions composite)	unverifiable	third-party CI provider vars, out of Trunk-source scope

Blocker before publishing: the RSpec section is wrong about the gem's current state. The rspec_trunk_flaky_tests gem already extracts the full set of exceptions from a RSpec::Core::MultipleExceptionError (it maps over exception.all_exceptions in both the message and backtrace formatters). The PR says the gem "is being extended to extract the full set; until that ships, check the CI job logs" — that work has already shipped on the upload side. If the dashboard still shows only one exception, that is a frontend/backend rendering issue downstream of the gem, not a gem limitation, so the "until that ships" framing should be corrected or removed. Recommend an eng confirm on where the single-exception truncation actually happens (display layer vs. ingestion) before merging.

The remaining unverifiable items are operational/third-party claims (upload latency, Go test JSON behavior, CI provider env vars), not Trunk code constants. They are not blockers on their own, but the 10-minute latency figure and the Go 0ms behavior should be sanity-checked with eng since they aren't backed by a source constant.

---

Source #1 — trunk-analytics-cli prints a Bundle Upload ID (confirmed)

File: trunk-io/analytics-cli/cli/src/upload_command.rs#L644-L645

pub fn get_bundle_upload_id_message(bundle_upload_id: &str) -> String {
    format!("🏷️  Bundle Upload ID: {}", bundle_upload_id)

Reasoning: The CLI emits a literal Bundle Upload ID: <id> line to the job log via get_bundle_upload_id_message, called when styling the upload output (line 670). The doc's wording ("prints a Bundle Upload ID to the job log") matches the source exactly, including casing.

Source #2 — RSpec gem already extracts the full exception set (contradicted)

File: trunk-io/analytics-cli/rspec-trunk-flaky-tests/lib/trunk_spec_helper.rb#L261-L280

def legacy_format_exception_message(exception)
  case exception
  when RSpec::Core::MultipleExceptionError
    messages = exception.all_exceptions.map { |e| "#{e.class}: #{e.message}" }
    strip_ansi_codes("#{exception.class}: #{messages.join(' | ')}")
  ...
def legacy_format_exception_backtrace(exception)
  case exception
  when RSpec::Core::MultipleExceptionError
    strip_ansi_codes(exception.all_exceptions.map do |e|
      ...
    end.join("\n\n"))

Reasoning: Both the message formatter and the backtrace formatter special-case RSpec::Core::MultipleExceptionError and iterate exception.all_exceptions, joining every captured exception (messages with |, backtraces with blank lines). The gem already produces the complete set on the upload side, so the doc's claim that the gem "is being extended to extract the full set" and that this work hasn't shipped ("until that ships") is contradicted. Correct framing: the gem extracts all exceptions today; any single-exception truncation the user sees is downstream of the gem.

Source #3 — "failure detail view surfaces only one exception" (ambiguous)

File: trunk-io/analytics-cli/rspec-trunk-flaky-tests/lib/trunk_spec_helper.rb#L263-L280

when RSpec::Core::MultipleExceptionError
  messages = exception.all_exceptions.map { |e| "#{e.class}: #{e.message}" }
  strip_ansi_codes("#{exception.class}: #{messages.join(' | ')}")

Reasoning: The claim "the failure detail view currently surfaces only one of the captured exceptions" is a behavioral claim about the dashboard render, not the gem. The gem clearly uploads all exceptions (Source #2), so if the UI shows one, the truncation is in a layer not visible in this repo (frontend in trunk2, or the ingestion/decoder path). I could not trace the dashboard render to confirm or refute single-exception display, so this is ambiguous. Needs an eng check on whether the truncation is real and, if so, where it lives.

Source #4 — Bundle Upload ID has no dashboard URL / search field (unverifiable)

File: n/a (absence claim)

Reasoning: This asserts the absence of a feature (no URL mapping, no search field for the Bundle Upload ID). Absence is not provable from a code search. The ID does flow through the backend (it appears in S3 key patterns and proto definitions, e.g. trunk/services/cli/src/flaky.ts and edge_service.proto), but whether the web app exposes a lookup is a frontend/product question. Treat as a product-state claim for eng to confirm, not a code fact.

Source #5 — Go 0ms subtest duration confuses AI failure analysis (unverifiable)

File: n/a

Reasoning: Two stacked claims: (a) go test does not always emit per-subtest durations (third-party go test -json behavior), and (b) Trunk's AI failure analysis mistakes a 0ms subtest for instantaneous and loses timing context. No accessible Trunk source handles per-subtest duration normalization, and the AI-analysis behavior is not expressed as a verifiable constant or rule. Both are out of reach of a source check; (b) in particular should be confirmed with eng before publishing as fact.

Source #6 — uploads take up to 10 minutes to populate (unverifiable)

File: n/a

Reasoning: No ingestion-latency constant or SLA of "10 minutes" exists in source for run-data population. The 10 minutes hits in the org are unrelated (linter timeouts, merge-queue setup copy, datadog log defaults). This is an operational/SLA figure that should be validated with eng rather than asserted from code.

Source #7 — CI per-worker URL environment variables (unverifiable against Trunk source)

File: n/a (third-party)

Reasoning: CIRCLE_BUILD_URL, BUILDKITE_BUILD_URL, CI_JOB_URL, and the GitHub Actions composite (${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}) are CI-provider-defined variables, not Trunk source. They are standard and well documented by each provider, but per the skill's scope, third-party API/env claims are out of scope for source verification. No Trunk-source contradiction; flagged only so a reviewer knows they were not verified here.