[shuke987]

What problem does this PR solve?

Issue Number: None

Related PR: #69581

Problem Summary: The BE header-dependency gate rejects util/threadpool.h once its reach exceeds 1087 translation units (the historical baseline of 988 plus 10%). Compile build 1081000 reported 1088 TUs. Clean master c3c7af57fa4 now reaches 1089 and reproduces the same failure.

Raise this baseline to 1200, making the effective limit 1320 TUs with the existing 10% allowance. This is an explicit dependency-budget relaxation to unblock builds and allow growth headroom. Other budgets, layering rules and the failure behavior remain unchanged; no reduction in compile cost is claimed.

Add an include-injection self-test confirming that spreading threadpool.h through common/logging.h still fails its reverse-reach budget and prints the diagnostic command, then restores to a passing state. Related PR #69581 adjusts the same entry as part of its Lance feature; this PR isolates the requested budget change.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
    • bash build-support/tests/run.sh: all seven gate self-test groups passed, including the new threadpool over-budget injection.
  • Manual test
    • bash build-support/check-build-hygiene.sh: fails on clean master at 1089 TUs; passes with this patch.
    • git diff --check: passed.
    • Local validation used an isolated source snapshot of master c3c7af57fa4. Full compilation is left to PR CI.
  • No need to test or manual test.

• Behavior changed:

  • No.
  • Yes. The build-time threadpool header reach limit rises from 1087 to 1320 TUs. Doris runtime behavior is unchanged.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[shuke987]

run buildall

[shuke987]

/review

[github-actions]

No actionable defect found in the two changed files at head 6307683. The change deliberately raises the threadpool reach ceiling from 1087 to 1320 TUs and adds a targeted regression check. There are no existing inline findings to carry forward and no additional user focus was supplied.

Independent read-only include-graph analysis counted 1089 TUs reaching util/threadpool.h on this head and 2488 after the hypothetical common/logging.h injection. Thus the new ceiling admits the current tree while the injection still exceeds it. The test requires both the threadpool-specific violation and its --reach diagnostic; overlapping guard failures cannot satisfy those checks by themselves.

Critical checkpoint conclusions:

• Goal and proof: the baseline change achieves the stated build-time budget relaxation; the added negative injection and existing clean/final-green checks cover enforcement and restoration by inspection.
• Scope and clarity: one budget entry and one focused self-test block; the commit explicitly explains the intended growth headroom.
• Concurrency and locks: no concurrent code or lock changes; the existing self-test runs serially and documents that it must not overlap a build in the same tree.
• Lifecycle and static initialization: logging.h is already backed up and covered by the EXIT trap; the new case restores it before later checks. No runtime or static-initialization lifecycle changes.
• Configuration: no operator configuration or dynamic setting added; this is a static budget table edit.
• Compatibility and rolling upgrades: no function symbols, wire contracts or storage formats change.
• Thrift/protobuf: no definition changes.
• Parallel paths: direct gate invocation, the aggregate hygiene entry and BE configure all use the same budget; other checks remain active.
• Conditional/error handling: the existing greater-than limit comparison and failure aggregation remain intact; the added test checks exit 1 and header-specific diagnostics.
• Test coverage: focused negative coverage and restore-to-green logic are present. The self-test and suite runner were inspected; builds and test suites were not executed in this static-only review.
• Test results: no expected-result artifacts change, and author-reported execution results were not independently reproduced.
• Observability: existing violation, reason, investigation command and fix guidance are preserved; the added test asserts the relevant diagnostic command.
• Transactions and persistence: not applicable to these build-support changes.
• Data writes, atomicity and crashes: no Doris data-write behavior changes; temporary self-test header edits use the existing backup/restore mechanism.
• FE/BE variable propagation: no variables or protocol fields added.
• Performance: production graph traversal is unchanged; the self-test adds one invocation of the existing text-only gate.
• Other core invariants: no changes to database visibility, versioning, delete bitmaps or runtime memory ownership, and no other substantiated defect found.

Coverage includes the full authoritative diff, gate callers, include-graph counting and diagnostics, test assertions and restoration, portability, and an independent risk-focused review of the injected edge. No unresolved candidate or uncovered static-review scope remains. Validation is limited to static inspection and read-only graph analysis; no runtime/build/test execution is claimed.

Review converged after 2 round(s).

[shuke987]

skip buildall