Support simulation mode for unit test targets#13290
Conversation
37679e3 to
55636d1
Compare
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
tclinkenbeard-oai
left a comment
There was a problem hiding this comment.
Generated by Codex.
What is it trying to do?
This CL adds a --simulation execution mode to standalone unit-test targets backed by fdbclient, fdbrpc, and fdbserver, while rejecting that option for unsupported targets such as flow_test. It initializes Sim2, simulated filesystems, per-process transports, an HTTP server process for simulated HTTP/mock-S3 tests, simulation-aware knobs, and filters noSim/ tests by default when simulation mode is selected. It also adds the missing fdbserver_core dependency required by the mocks3 unit-test target after the new server-knob initialization dependency.
Is it correct?
Yes, based on code inspection. The runner only selects simulation setup for targets that supply an initializer, and the initializer is awaited before executing tests. The new startup path establishes the simulated network before tracing or test execution, switches execution to the test process, and creates the simulated filesystem and transport state expected by affected unit tests. The HTTP process initialization is consistent with the existing simulated HTTP registration path used by HTTPServer.cpp and MockS3Server.cpp.
I also checked the apparent lifetime concern around discarding the value returned from FlowTransport::bind(): bind() retains the listener future internally, and its return value is used by other callers only to observe listener errors, so this is not a correctness issue for these simulated bindings.
This change does not add serialized messages, durable records, or independently versioned outputs, so I found no protocol-compatibility boundary requiring version gating. It also does not place new work on a production hot path; the added filtering and initialization occur only in standalone unit-test invocation.
At the current head, all visible PR checks are succeeding, including FoundationDB CI PR Builder, clang, clang arm, clang-ide, macOS, macOS_m1, PR Cluster Tests, and Test Boost CONFIG Mode on Windows. Earlier build failures were on the previous commit before the mocks3 dependency fix.
No build, unit-test, or simulation validation was run as part of this review.
Are there bugs?
I did not find any correctness bugs.
Are there omissions?
There is no automated regression coverage added for the new command-line mode, unsupported-target rejection, or the default noSim/ filtering behavior. The PR description states that the simulation invocation was exercised, and the current public CI results are green, so I do not think this omission blocks the change; a focused runner-level regression would still make this behavior easier to preserve.
Are there better ways of doing things?
A small test covering --simulation option handling and noSim/ selection behavior would be preferable to relying only on invocation-level validation. I do not see a necessary implementation rewrite beyond that.
Should this CL be LGTMd?
Yes, LGTM. I inspected the runner changes, simulator/process/bootstrap initialization, knob setup, HTTP/mock-S3 support path, and target linkage update. The highest remaining risk is untested regression in the new option/filtering behavior, which does not appear blocking given the scoped code path and successful current checks.
saintstack
left a comment
There was a problem hiding this comment.
Nice addition. Worth a mention in documentation/sphinx/source/testing.rst ? So it'll get noticed/used?
This PR extends unit test targets (e.g.
fdbserver_commitproxy_test) to support running unit tests in simulation. This is not possible forflow_test, which doesn't have access to the simulator. Validated by running unit test targets with the simulation flag.