Nested Cargo calls and session IDs

[weihanglo]

Problem

With -Zbuild-analysis, Cargo assigns a unique session ID to each invocation for logging purpose. However, this creates challenges when Cargo calls itself recursively (for example cargo fix) or when external build orchestrators call Cargo multiple times within a single "build session." These use cases might want a way to correlate all calls.

Currently, each nested call gets its own session ID, making it difficult to associate related logs across the entire build process.

Proposed Solution

Some possible solutions:

• Do nothing. Nested calls get unique IDs (timestamp will be different unless the machine is really, really fast)
• Allow callers to specify a custom session ID that nested calls can inherit or reference.
  • For logging we might need to capture this field as well. For example build-started event can have a custom_metadata field for external build orchestrators
• Generate hierarchical session IDs automatically. For example, parent session ID as prefix, and with unique suffixes for each nested call

Notes

Part of #15844

See also

• https://internals.rust-lang.org/t/introduce-env-var-cargo-run-id-for-identifying-related-processes-threads/21134
• Detecting invocations of nextest nextest-rs/nextest#416

[epage]

timestamp will be different unless the machine is really, really fast

Isn't this a bug with the current system that we have race conditions for creation of log entries?

If we resolve that by turning timestamp-workspace into timestamp-workspace-random, we could do timestamp-workspace-parentrandom-childrandom where

• parentrandom is all 0s for a root command
• unsure if we should have everything assigned back to the parent workspace or have that change with each call.

Note that cargo nextest has a NEXTEST_RUN_ID and iirc @sunshowers had been wondering about Cargo having some feature like this.