[Jackie-Jiang]

QueryKillingIntegrationTest can fail when offlineSystemActivitiesCpuTimeNs is zero, even though InstanceResponseOperator explicitly clamps this estimate of unaccounted wall time to zero. Allow nonnegative values in both resource usage tests, retaining the positive measured CPU/memory checks and total consistency assertions.

Observed in this CI failure.

Validation: all 7 QueryKillingIntegrationTest tests passed on current master with the CI lane settings (2 active processors, 1 GB initial heap, 4 GB maximum heap), with compiler warnings enabled. Spotless, Checkstyle, and license checks passed. An initial run using default local JVM settings exhausted the heap in the existing CPU-killing scenario before reaching the changed assertion.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.37%. Comparing base (091eac7) to head (6f84678).

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #20159      +/-   ##
============================================
+ Coverage     70.36%   70.37%   +0.01%     
  Complexity     1522     1522              
============================================
  Files          3571     3571              
  Lines        238859   238859              
  Branches      38472    38472              
============================================
+ Hits         168065   168107      +42     
+ Misses        57999    57961      -38     
+ Partials      12795    12791       -4     

Flag	Coverage Δ
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-25	70.37% <ø> (+0.01%)	⬆️
lane-a	100.00% <ø> (ø)
lane-b	0.00% <ø> (ø)
temurin	70.37% <ø> (+0.01%)	⬆️
unittests	70.37% <ø> (+0.01%)	⬆️
unittests1	59.50% <ø> (+0.01%)	⬆️
unittests2	41.90% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[xiangfu0]

Looks good to me. offlineSystemActivitiesCpuTimeNs is an estimate: wall − mainThreadCpu − workerCpu/N. InstanceResponseOperator.calSystemActivitiesCpuTimeNs deliberately clamps it at 0 (and returns 0 when the main thread CPU is 0). The phase model assumes the main thread and the workers run one after another, but on a tiny SELECT * … LIMIT 5 on a 2-core runner their CPU time can overlap, so 0 is a legal result, not an accounting bug. The checks that matter are kept: thread CPU, serialization CPU and memory must still be > 0, and the total must still equal the sum of its parts. ThreadCpuTimeMeasurementTest still covers the formula itself.

Small gap, not blocking: the integration test no longer catches the system-activities value being dropped on its way from server to broker, because a missing value also reads as 0. DataTableSerDeTest covers the serialization part of that path.

Risk: LOW. Test-only change. It brings the assertion in line with the documented clamp-at-0 behavior, and no production code or contract changes.
Reviewed SHA: 6f84678 (merge-base 091eac7)
Validation: every check run at this SHA passed, including Integration Test Set 2, which runs Q*Test in lane-a, plus Set 1, Unit Sets 1 and 2 and the Linter and the compatibility runs. Locally, at this SHA on Temurin 25.0.5 with 2 active processors and a 1g/4g heap, QueryKillingIntegrationTest passed: 7 tests, 0 failures, 0 skipped. A throwaway probe sent the SELECT * LIMIT 5 query 400 times (200 with 2 processors, 200 with 4) and never got a 0 (smallest value about 24 µs), so a 0 is a rare timing case. Proof that it can happen comes from the clamp in the source plus the linked CI failure, not from a local repro.
Decision: APPROVE

AI-generated review via IntentLab · Model: Claude Opus 5.5 (claude-opus-5-5).