No issue for this. I was working on #26216 and decided to make this change.

This alters the logging behaviour and UX for the TestServer harness that is used in our integration tests in the influxdb3 crate.

Changes

The primary change is the addition of a CLI argument for the serve command (--tcp-listener-file-path) that the server will use to write out the listener address that it is listening for TCP connections on.

The argument is hidden and defaults to None.

This can be used by our test harness, which uses a bind address of 0.0.0.0:0 in order to select a randomly available port.

The test harness creates a temporary file and waits for it to be written to acquire the selected address of the underlying process.

Why this is an improvement

Previously, the TestServer was doing some weird business to capture the stdout of the running process and grab the log line that displays the listener address. This created a couple of issues:

• we couldn't customize the log filter on the running process via the normal means of setting the RUST_LOG environment variable
• the re-emitted logs were not formatted in the terminal and therefore were difficult to read

Usage

The TEST_LOG environment variable is still respected, and is required in order to have logs emitted by the underlying influxdb3 process.

One can run tests like so:

TEST_LOG= cargo nextest run -p influxdb3 --nocapture

This will have the underlying process emit logs at the INFO level (and above). This is how it operated before this PR.

Or, providing a filter:

TEST_LOG=influxdb3=debug,info cargo nextest run -p influxdb3 --nocapture

This will pass the provided filter down to the underlying influxdb3 process (influxdb3=debug,info)

The RUST_LOG enfironment variable is also respected, so

TEST_LOG= RUST_LOG=influxdb3=debug,info cargo nextest run -p influxdb3 --nocapture

Will enable log output for the underlying influxdb3 process while passing the filter provided to RUST_LOG to the underlying process.