#35957 ci: Enable Boost.MultiIndex invariant-checking mode
| Reviewability | Reviews | Agreement | Size | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| #35957 ci: Enable Boost.MultiIndex invariant-checking mode | Ready | 0 | Strong | 0 + 5 tests | ||||||
|
|
|
|
| ||||||
Reviewability: ReadyStalePaused Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs. Size: lines added or modified outside tests, then in tests; greener = smaller. | ||||||||||
Goal
This PR enables the `BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING` preprocessor definition in two CI jobs (`i686_no_ipc` and `native_previous_releases`) that already test with `BOOST_MULTI_INDEX_ENABLE_SAFE_MODE`. It leaves the MSAN fuzzing job untouched and adds an inline comment documenting that enabling invariant checks there would exceed the CI runner's 240-minute execution limit.
Problem: CI jobs currently run with Boost.MultiIndex safe mode enabled but without invariant checking, missing internal container validity checks on operations in debug builds.
Evidence of importance:
- PR description quotes Boost.MultiIndex documentation noting invariant checking adds runtime validation of data structure invariants.
- PR description and commit message note that the MSAN fuzz CI job is deliberately excluded because invariant checks push it beyond the 240-minute runner limit.
Risk of a mistake: low (tests). It only modifies compiler flags and comments in CI environment setup scripts.
Changed since the previous assessment: No substantive changes to the diff; rebased on updated master.
Reviewability
Ready
Nothing known that would invalidate a review now.
Waiting on (from the thread read):
- reviewer: review following author rebase and local timing clarifications 2026-10-02
- reviewer: review of rebased PR 2026-10-02
Agreement
Strong
substantive support, no open objection (jeanpablojp)
Thread notes: Added jeanpablojp's question regarding the CI timeout limit (rc:3833595222), which was clarified and accepted. fanquake's commit message phrasing suggestion (c:5266830859) is excluded per project style/naming rules. / Added suggestions and questions missed under schema 1 (c:5266830859, c:5278261293 part 2, rc:3833595222). Updated waiting_on to reflect author rebase.
Objections, suggestions, and questions:
| Reviewer | Type | Harm, request, or question | Status | Must be | Author replied | Quote |
|---|---|---|---|---|---|---|
| fanquake (member) | suggestion, style | Update commit message to specify defining invariant checking rather than safe mode which is already defined | fixed · fix pushed · author updated the commit message | changed | yes | 2026-08-12: 'This is already defined? Shouldn't the commit message be "ci: Define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING for debug builds"?' Status from: 2026-08-12: hebasto: 'Thanks! Fixed.' |
| fanquake (member) | objection, correctness | times out the MSAN fuzz CI job | answered · author replied with local benchmark duration | answered | yes | 2026-08-13: 'Looks like this times out the MSAN fuzz job.' Status from: 2026-08-13: hebasto: 'It took 214 min on my machine with 16 cores.' |
| fanquake (member) | question, correctness | How long did the MSAN fuzz job take when tested locally? | answered · author replied with run duration | answered | yes | 2026-08-13: 'How long did it take when you tested it locally?' Status from: 2026-08-13: hebasto: 'It took 214 min on my machine with 16 cores.' |
| jeanpablojp (contributor) | question, correctness | whether the job timeout is 180 minutes rather than 240 minutes | accepted · author pointed to CI run configuring 240 minutes, which reviewer accepted | answered | yes | 2026-08-21: 'The run that timed out died with "exceeded the maximum execution time of 3h0m0s", and `ci.yml` has `timeout-minutes: 180` for this job. So 180 here, not 240. Doesn't change the conclusion, just the number.' Status from: 2026-08-22: jeanpablojp: 'Ah, hadn't seen that run. I'd gone looking in `ci.yml` and found 180 for this job, that's where my question came from. Thanks for clarifying.' |
Support:
- jeanpablojp (contributor) (Approach ACK, 2026-08-21) [tested: msan fuzz job]: Ran the msan fuzz job here too, 16 threads, 208 min. It matches your 214.
Participants:
- fanquake (member, objection, 2 statements 2026-08-12 to 2026-08-13): objected that MSAN fuzz job times out; author replied with local timing
- jeanpablojp (contributor, support, 3 statements 2026-08-21 to 2026-08-22): Approach ACK after confirming local runtime of the MSAN fuzz job
Files
7 lines under test/bench/ci.
- ci/test/00_setup_env_native_fuzz_with_msan.sh +3/-0
- ci/test/00_setup_env_i686_no_ipc.sh +1/-1
- ci/test/00_setup_env_native_previous_releases.sh +1/-1
Card
The short text the ranking pass compares across PRs.
This PR enables Boost.MultiIndex invariant checking in two existing CI debug jobs that already test safe mode. The check catches potential multi-index container corruption or invariant violations during functional tests in CI. The MSAN fuzzing job is intentionally left without the flag to avoid exceeding runner timeouts.
Data
thread read through 2026-10-02 (9 statements), head da74d32b0f
labels: Tests
Categories
Build and CI
P3 · test coverage
Enables Boost.MultiIndex invariant checking in two existing CI test jobs. This adds automated runtime validation of container internal data structures during CI runs without significant downside.
Membership: Modifies CI configuration scripts under ci/test/ to add preprocessor definitions to test environments.
Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 0
Test infrastructure
P3 · test coverage
Enables BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING to validate container invariants during test runs. While useful for catching data structure corruption bugs early, it is reasonably deferrable maintenance.
Membership: Carries the Tests label and configures container invariant verification for test suites run in CI.
Factors: security/stability 1, bug 0, performance 0, user value 0, leverage 0