Skip to content

[chore](thirdparty) Upgrade Apache Arrow to 24.0.0 - #66221

Merged
Gabriel39 merged 19 commits into
apache:masterfrom
hubgeter:worktree/apache-master-20260727
Aug 5, 2026
Merged

[chore](thirdparty) Upgrade Apache Arrow to 24.0.0#66221
Gabriel39 merged 19 commits into
apache:masterfrom
hubgeter:worktree/apache-master-20260727

Conversation

@hubgeter

Copy link
Copy Markdown
Contributor

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: Doris used Apache Arrow 17.0.0, which blocked consuming newer Arrow fixes and APIs. Upgrade the C++ third-party dependency to 24.0.0, align xsimd with Arrow 24, port the Paimon row-group, INT96, and Parquet LZO compatibility patches, add Arrow Compute to the static dependency graph, and migrate removed Arrow and Parquet APIs while preserving Decimal128 semantics.

Release note

None

Check List (For Author)

  • Test

    • Regression test
    • Unit Test
    • Manual test (add detailed scripts or steps below)
    • No need to test or manual test. Explain why:
      • This is a refactor/code format and no logic has been changed.
      • Previous test can cover this change.
      • No code files have been changed.
      • Other reason
  • Behavior changed:

    • No.
    • Yes.
  • 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

### What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: Doris used Apache Arrow 17.0.0, which blocked consuming newer Arrow fixes and APIs. Upgrade the C++ third-party dependency to 24.0.0, align xsimd with Arrow 24, port the Paimon row-group, INT96, and Parquet LZO compatibility patches, add Arrow Compute to the static dependency graph, and migrate removed Arrow and Parquet APIs while preserving Decimal128 semantics.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Built the Arrow third-party dependency
    - Built the Paimon C++ third-party dependency from clean sources
    - Built BE with `./build.sh --be`
    - Verified the Arrow and Paimon patches apply cleanly from pristine sources
    - Ran `build-support/check-format.sh`
    - Relevant C++ unit test source was updated but not built or run
- Behavior changed: No
- Does this need documentation: No
@hello-stephen

Copy link
Copy Markdown
Contributor

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?

@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@hubgeter

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Request changes: the Arrow 24 upgrade has two build-delivery blockers. The clean Linux third-party job succeeds, but both supported macOS third-party jobs fail at Arrow configuration, and an incremental Paimon source tree skips the new compatibility patch set.

Checkpoint conclusions:

  • Goal and test sufficiency: not achieved on all supported paths; no upgrade-specific behavioral test was added, and the failed paths must be rerun after the fixes.
  • Scope: all 13 authoritative changed paths and their Arrow/Paimon/build consumers were reviewed; the source changes are otherwise focused.
  • Concurrency: no new shared-state or locking defect was introduced; Arrow's parallel column-reader ownership remains valid.
  • Lifecycle and cleanup: runtime ownership/error cleanup is preserved, but extracted Paimon patch state is stale across an incremental upgrade (inline finding 2).
  • Configuration and dynamic behavior: Arrow 24's CMake 3.25 floor conflicts with Doris's pinned 3.22.1 supported toolchains (inline finding 1).
  • Compatibility and rolling upgrade: no persisted-data, journal, RPC, or storage-format rolling-upgrade change was found; source/API and prebuilt-library compatibility are blocked by the two findings.
  • Parallel and equivalent paths: Linux fresh-source third-party CI passes; macOS and macOS-arm64 fail, macOS BE lacks the matching Compute archive, and an existing Paimon source directory follows the stale-marker path.
  • Special conditions: malformed LZO, INT96 unit variants, projected/selected row groups, and decimal precision boundaries were traced. The empty-row-group truncation is real but behaviorally identical in the base Arrow 17 patch, so it is not attributed to this PR.
  • Tests and results: review-only, so no local build/test was run. Live CI currently has Linux third-party passing; both macOS third-party jobs and macOS BE failing; Doris compile and BE UT pending.
  • Observability: the build failures are explicit; no additional runtime observability regression was found.
  • Persistence, transactions, data writes, and new variables: no new transaction/persistence or FE/BE variable path applies; the ported writer accounting and data semantics showed no PR-introduced defect.
  • Performance: no substantiated CPU, memory, I/O, or link-time performance regression was found.
  • Other issues: no additional nonduplicate issue remained after two convergence rounds.

No additional user-provided review focus was supplied; the whole PR was reviewed.

Comment thread thirdparty/vars.sh Outdated
ARROW_NAME="apache-arrow-17.0.0.tar.gz"
ARROW_SOURCE="arrow-apache-arrow-17.0.0"
ARROW_MD5SUM="ba18bf83e2164abd34b9ac4cb164f0f0"
ARROW_DOWNLOAD="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/apache/arrow/archive/refs/tags/apache-arrow-24.0.0.tar.gz"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Raise the supported CMake floor before selecting Arrow 24

Arrow 24's cpp/CMakeLists.txt now requires CMake 3.25, but both macOS third-party workflows explicitly install 3.22.1 (and the gcc10 compilation image pins the same version). The current macOS and macOS-arm64 jobs both fail at this configure step with CMake 3.25 or higher is required; CMAKE_POLICY_VERSION_MINIMUM cannot override cmake_minimum_required. Please update every supported Arrow build path to provide CMake >=3.25 and regenerate the matching prebuilt archives before adopting this version, otherwise the standard macOS/toolchain builds remain unusable.

Comment thread thirdparty/download-thirdparty.sh Outdated
fi
for patch_file in \
"${TP_PATCH_DIR}/paimon-cpp-buildutils-static-deps.patch" \
"${TP_PATCH_DIR}/paimon-cpp-arrow-24-compatibility.patch"; do

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Invalidate the old Paimon patch marker

PAIMON_CPP_SOURCE is unchanged, so an incremental tree already patched on the base commit still has patched_mark. This guard then skips this whole new loop, including paimon-cpp-arrow-24-compatibility.patch, leaving the removed three-argument unique_ptr out-parameter GetRecordBatchReader calls and bare RETURN_NOT_OK uses in place when building against Arrow 24. Please invalidate/re-extract the source when the patch set changes (for example with a patch-set-specific marker or a bumped source identity), so the documented rerunnable download flow cannot silently retain incompatible sources.

### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 requires CMake 3.25, while the macOS thirdparty workflows and gcc10 image selected older CMake releases. The macOS BE job also consumed a stale prebuilt Arrow archive, incremental Paimon sources skipped the new compatibility patch, and a BE unit test still initialized Arrow Flight Ticket as an aggregate. Raise the supported CMake floor, rebuild Arrow and Paimon for macOS thirdparty changes, version the Paimon patch marker, and use the Arrow 24 Ticket constructor.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Parsed the modified GitHub Actions workflows as YAML
    - Checked shell syntax and clean, incremental, and repeated Paimon patch flows
    - Checked the Arrow 24 Ticket constructor with a C++20 syntax compile
    - Ran build-support/check-format.sh
- Behavior changed: No
- Does this need documentation: No
@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@hubgeter

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Request changes: the Arrow 24 upgrade still has one build-delivery blocker and one CI integration-coverage defect. The targeted macOS path cannot obtain xsimd 14, and the generic third-party trigger rebuilds only Arrow/Paimon.

Checkpoint conclusions:

  • Goal and test sufficiency: not achieved on the targeted supported macOS path. The changed BE tests adapt Arrow APIs but do not exercise third-party source acquisition or generic third-party-to-BE integration.
  • Scope: all 17 authoritative changed paths and their Arrow/Paimon/build consumers were reviewed. The upgrade is mostly focused, but the new macOS trigger is broader than its implementation.
  • Concurrency: no runtime shared-state, locking, or static-initialization defect applies to these build and API changes.
  • Lifecycle and cleanup: runtime reader/writer ownership and error propagation remain intact; workflow source/prebuilt artifact lifecycle is broken by inline finding 1, and dependency selection is stale in inline finding 2.
  • Configuration: no dynamic Doris configuration item was added. Current-head CMake/toolchain selection is compatible with Arrow 24, and no separate configuration defect survived validation.
  • Compatibility: the inspected Arrow 24 API migrations, INT96 property propagation, row-group behavior, and Doris external-Arrow Paimon path are consistent. No persisted-data, journal, RPC, or rolling-upgrade format defect was found.
  • Parallel paths: Linux, Intel/arm64 macOS, fresh/incremental source, Doris external-Arrow Paimon, and final static-link paths were traced. The unsupported standalone Paimon bundled-Arrow branch was not treated as a Doris defect.
  • Special conditions: the broad thirdparty/** condition does not match the hard-coded dependency set rebuilt (inline finding 2); no other incorrect conditional path survived validation.
  • Test coverage: no upgrade-specific end-to-end test covers source-bundle closure or generic third-party-to-BE integration.
  • Test results: review-only, so no local build/test was run. Live BE UT (macOS) currently fails exactly because 14.0.0.tar.gz is missing; style, license, secret, and dependency checks pass, while the full third-party and Doris compile checks were still pending at freeze time.
  • Observability: the CI failure is explicit and diagnostic; no additional runtime logs or metrics are needed for this change.
  • Persistence, transactions, and data writes: no FE journal, transaction, storage-version, or atomic data-write path is modified.
  • FE/BE propagation: no new FE/BE variable or protocol field is introduced.
  • Performance: no substantiated runtime CPU, memory, or I/O regression was found. The broad macOS trigger adds avoidable CI work while still providing stale integration coverage, as noted inline.
  • Other issues: the remaining CMake-floor and incremental patch-marker concerns are already covered by existing P1 threads, so they were not duplicated. The apparent LZO include failure was disproved because thrift::thrift propagates the installed include root to Parquet's object target.

No additional user-provided review focus was supplied; the whole PR was reviewed.

-o doris-thirdparty-source.tgz
tar -zxvf doris-thirdparty-source.tgz
export MACOSX_DEPLOYMENT_TARGET=12.0
./build-thirdparty.sh -j "$(nproc)" arrow paimon_cpp

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Fetch xsimd 14 before this targeted Arrow build

Passing only arrow paimon_cpp restricts download-thirdparty.sh to those two archives, but Arrow is configured with xsimd_SOURCE=BUNDLED and a local ${TP_SOURCE_DIR}/14.0.0.tar.gz URL. The shared source bundle does not contain that newly selected archive, so the live macOS job fails in xsimd_ep with File not found: .../thirdparty/src/14.0.0.tar.gz before Arrow is compiled. Please download Arrow's complete source-only dependency closure (at least xsimd) before this targeted build, or provide a source bundle guaranteed to match the checked-out vars.sh.

Comment thread .github/workflows/be-ut-mac.yml Outdated
# A thirdparty upgrade can make the shared prebuilt archive stale.
# Rebuild the changed Arrow/Paimon stack before compiling BE so this
# job validates the versions selected by the PR.
if [[ "${{ steps.filter.outputs.thirdparty_changes }}" == "true" ]]; then

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P2] Align this broad trigger with the dependency set actually rebuilt

thirdparty_changes matches every file under thirdparty/**, but this branch always rebuilds only Arrow and Paimon. For example, a protobuf version or patch change triggers this BE job while both Arrow and BE still consume protobuf from the shared prebuilt, so a green result would not validate the PR-selected dependency as the new comments imply. Please either narrow the filter to the Arrow/Paimon inputs this step covers or derive and rebuild the changed dependency set (including the required transitive closure).

hubgeter added 2 commits July 30, 2026 14:55
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The targeted macOS build omitted Arrow bundled xsimd and Brotli sources and claimed coverage for unrelated thirdparty changes. Incremental Paimon source trees could also skip the Arrow Compute patch delta, and the maintained AArch64 build image selected CMake 3.22 although Arrow 24 requires 3.25. Fetch the complete targeted source closure, scope the workflow to dedicated Arrow/Paimon inputs, version the Compute patch independently, upgrade the AArch64 CMake selection, and normalize patch whitespace.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Rebuilt Paimon C++ against Arrow 24
    - Verified pristine, incremental, and repeated patch flows
    - Ran thirdparty shell tests, workflow YAML parsing, shell syntax checks, and build-support/check-format.sh
- Behavior changed: No
- Does this need documentation: No
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The targeted macOS Arrow/Paimon validation could be skipped when its shared download and build entry points changed. Its live job also selected Homebrew CMake 4.4.0, which fails while configuring Paimon bundled Snappy 1.1.10. Track every direct integration input and pin the same CMake 3.25.3 used by the full macOS thirdparty jobs.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Verified the live macOS failure log with gh
    - Parsed the modified workflow YAML and ran git diff --check
- Behavior changed: No
- Does this need documentation: No
@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 0.00% (0/1) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 59.05% (25558/43285)
Line Coverage 43.13% (256279/594178)
Region Coverage 38.82% (203053/523034)
Branch Coverage 40.16% (92577/230543)

@hello-stephen

Copy link
Copy Markdown
Contributor

BE UT Coverage Report

Increment line coverage 0.00% (0/1) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 59.06% (25571/43296)
Line Coverage 43.14% (256363/594222)
Region Coverage 38.83% (203102/523058)
Branch Coverage 40.17% (92604/230557)

### What problem does this PR solve?

Issue Number: close apache#66221

Related PR: apache#66221

Problem Summary: Arrow 24 writes smaller Parquet column chunks than the previous Arrow version. The Iceberg write statistics regression test still expected the old physical column sizes even though record counts, null counts, bounds, and query results remained correct. Update the generated expectation to the result produced by the TeamCity external regression run with Arrow 24.

### Release note

None

### Check List (For Author)

- Test: TeamCity External Regression generated result comparison
- Behavior changed: No
- Does this need documentation: No
@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@hubgeter

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed current head 1f017bb6c4b83d0b6ca16f25456ae1ef16b387b0. I found no new nonduplicate issue. The xsimd source-closure, Paimon marker, and broad-trigger defects are addressed on this head; the existing CMake-floor P1 still applies to docker/compilation/Dockerfile.gcc7, which remains on CMake 3.12.3 while Arrow 24 requires 3.25.

Checkpoint conclusions:

  • Goal and test sufficiency: the Arrow 24/xsimd/Paimon migration is coherent across source acquisition, patching, compilation targets, runtime API migrations, and the changed semantic tests apart from the already-threaded gcc7 CMake floor.
  • Scope: all 20 authoritative changed files and their relevant build/runtime consumers were reviewed; the changes remain focused on the dependency upgrade and its integration.
  • Concurrency: no new shared-state, locking, static-initialization, or parallel-reader ownership defect was found.
  • Lifecycle and cleanup: fresh and incremental Paimon patch states converge, source/prebuilt selection is consistent, and reader/writer ownership and error propagation remain intact.
  • Configuration and dynamic behavior: current Linux, macOS, gcc10, and arm paths select CMake >=3.25 and the complete Arrow source-only dependency closure. The maintained gcc7 image remains below the floor under the existing P1; no Doris runtime configuration path is added.
  • Compatibility and rolling upgrade: Decimal128 preserves Doris/Iceberg's supported precision, Flight/Paimon API migrations are complete, and no persisted-data, journal, RPC, or storage-format incompatibility was found.
  • Parallel and equivalent paths: Linux, Intel/arm64 macOS, gcc10/arm/gcc7 images, fresh/incremental sources, Paimon external-Arrow targets, and final BE static linkage were traced. The gcc7 residue is covered by the existing broad CMake-floor thread rather than duplicated here.
  • Special conditions: selected/final/empty row groups, compressed-byte thresholds, forced INT96, malformed/truncated LZO framing, decimal precision boundaries, and source-marker partial states were checked. The empty-row-group termination edge is inherited unchanged from the Arrow 17 patch.
  • Tests and results: review-only, so no local build or test command was run. The changed tests exercise Decimal128 alignment, Flight ticket serialization, external-reader behavior, and Iceberg Parquet metrics; live third-party and BE jobs were still running at the review freeze.
  • Observability: build/setup failures remain explicit in CI and no runtime logging or metrics regression was introduced.
  • Persistence, transactions, data writes, and new variables: no FE journal, transaction protocol, storage-version, atomic-write, or FE/BE variable-propagation path is added; writer property and statistics semantics remain consistent.
  • Performance: no substantiated CPU, memory, I/O, archive-link, or row-group-size regression was found.
  • Other issues: the apparent LZO include failure was disproved because thrift::thrift propagates the installed include root to Parquet's object target. No additional nonduplicate issue survived main-agent validation; the outstanding gcc7 build path remains covered by the live CMake-floor P1.

No additional user-provided review focus was supplied; the whole PR was reviewed.

@hello-stephen

Copy link
Copy Markdown
Contributor

BE Regression && UT Coverage Report

Increment line coverage 100.00% (1/1) 🎉

Increment coverage report
Complete coverage report

Category Coverage
Function Coverage 75.73% (31978/42228)
Line Coverage 60.39% (356476/590253)
Region Coverage 56.94% (298796/524780)
Branch Coverage 58.30% (134434/230588)

### What problem does this PR solve?

Issue Number: close apache#66221

Related PR: apache#66221

Problem Summary: Arrow 24 requires CMake 3.25 or newer, but the maintained gcc7 compilation image still built CMake 3.12.3. This left that source-build path unable to configure Arrow after the dependency upgrade. Build CMake 3.25.3 from the corresponding official source archive so every explicit Doris compilation-image CMake version satisfies the Arrow 24 floor.

### Release note

None

### Check List (For Author)

- Test: Verified the CMake 3.25.3 source archive and all explicit compilation-image CMake versions
- Behavior changed: No
- Does this need documentation: No
@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@hubgeter

Copy link
Copy Markdown
Contributor Author

/review

### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 rejects null values in Parquet fields declared non-nullable. The Iceberg schema-change regression test renames the required score column to grade, then inserts a row without grade, causing External Regression to fail before the type-conversion assertions. Supply an explicit grade value so the test remains valid under Arrow 24.

### Release note

None

### Check List (For Author)

- Test: No need to test (one-line regression input correction; validation is delegated to TeamCity per request)
- Behavior changed: No
- Does this need documentation: No
@hubgeter

Copy link
Copy Markdown
Contributor Author

run buildall

@github-actions

Copy link
Copy Markdown
Contributor

Codex automated review failed and did not complete.

Error: Codex completed, but no new pull request review was submitted for the current head SHA.
Workflow run: https://github.com/apache/doris/actions/runs/30601197902

Please inspect the workflow logs and rerun the review after the underlying issue is resolved.

@hubgeter

Copy link
Copy Markdown
Contributor Author

/review

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Request changes: the current Arrow 24 head leaves the scheduled macOS BE path on an incompatible Arrow 17 prebuilt. The PR-triggered overlay is green, but the scheduled build skips that overlay while BE now imports the separate Arrow Compute archive unconditionally.

Checkpoint conclusions:

  • Goal and test sufficiency: not achieved for the scheduled/default-branch path. The changed tests cover API migrations and Iceberg output, but no check validates the prebuilt's Arrow version or archive closure.
  • Scope: all 22 authoritative changed files and their relevant Arrow/Paimon, BE-link, workflow, patch, and test consumers were reviewed; the changes remain focused on the dependency upgrade and integration.
  • Concurrency: no new shared-state, locking, static-initialization, or parallel-reader ownership defect was found.
  • Lifecycle and cleanup: runtime reader/writer ownership and error propagation remain intact. The prebuilt/source artifact lifecycle is incompatible on the skipped scheduled path (inline finding).
  • Configuration and dynamic behavior: current-head Linux, macOS, gcc7, gcc10, and arm build definitions select CMake >=3.25; no Doris runtime configuration path is added. The scheduled workflow condition is the remaining configuration defect.
  • Compatibility and rolling upgrade: the Arrow 24 API migrations, Decimal128 mapping, INT96 property propagation, LZO port, and Paimon link graph are consistent. No persisted-data, journal, RPC, or storage-format rolling-upgrade defect was found; the current macOS prebuilt is binary-incompatible with the new unconditional Compute import.
  • Parallel and equivalent paths: clean Linux, macOS, and macOS-arm64 third-party builds and the PR-triggered macOS BE overlay pass. Scheduled and later BE-only runs skip that overlay and use the stale asset.
  • Special conditions: scheduled/default-branch event behavior, clean/incremental sources, selected/final/empty row groups, malformed LZO framing, INT96 units, Decimal128 precision, Flight tickets, and source-marker states were traced. The real zero-row-group termination edge is inherited unchanged from the Arrow 17 patch and is not attributed to this PR.
  • Tests and results: review-only, so no local build or test was run. Exact-head full third-party and targeted macOS BE checks pass. The TeamCity BE UT failure is in a test added on a newer integration revision and absent from the authoritative diff; external regressions were still pending at freeze time.
  • Observability: build and patch failures are explicit, but this workflow has no preflight assertion for the prebuilt Arrow version/archive set; that omission is part of the inline finding.
  • Persistence, transactions, data writes, and variables: no FE journal, transaction protocol, storage-version, atomic-write, or FE/BE variable-propagation path is introduced.
  • Performance: no substantiated runtime CPU, memory, I/O, or link-time performance regression was found.
  • Other issues: all other candidates were either duplicates of existing live threads or disproved as inherited base behavior.

No additional user-provided review focus was supplied; the whole PR was reviewed.

Comment thread .github/workflows/be-ut-mac.yml Outdated
# download/build entry points change.
# The shared source bundle can predate vars in the PR, so explicitly
# fetch Arrow's bundled source dependencies before the targeted build.
if [[ "${{ steps.filter.outputs.arrow_paimon_changes }}" == "true" ]]; then

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[P1] Keep scheduled builds off the stale Arrow 17 prebuilt

Paths Filter is skipped for schedule, so arrow_paimon_changes is empty and this branch never runs on the scheduled job. The current automation prebuilt used above contains libarrow.a, libarrow_dataset.a, and libarrow_acero.a but no libarrow_compute.a (and its source bundle still contains Arrow 17); only this PR-triggered branch installs libarrow_compute.a. Once the unconditional Compute import in be/cmake/thirdparty.cmake lands, scheduled master builds—and later BE-only PRs that do not set this filter—will try to link against that stale archive and fail. Please either regenerate/publish the version-matched prebuilt before landing and validate its Arrow version, or rebuild the Arrow/Paimon closure on the scheduled path as well. This is separate from the existing xsimd thread because scheduled runs never reach the targeted rebuild at all.

hubgeter added 3 commits July 31, 2026 15:32
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The scheduled macOS BE workflow and later BE-only pull requests skip the Arrow/Paimon overlay and reuse the shared automation prebuilt. That prebuilt currently uses Arrow 17 and lacks libarrow_compute.a, while the Arrow 24 integration imports that archive unconditionally. Validate the extracted Arrow major version and Compute archive, and rebuild the Arrow/Paimon closure whenever the artifact is stale or the relevant inputs changed.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Parsed the workflow YAML and exercised the rebuild predicate for Arrow changes, stale scheduled artifacts, and current BE-only artifacts
- Behavior changed: No
- Does this need documentation: No
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The macOS BE workflow recovered from the known stale Arrow 17 prebuilt, but a missing Arrow config header exited under bash errexit before recovery, and a hard-coded major-only comparison could accept an artifact that did not match the selected Arrow release. Validate the exact manifest-derived Arrow version and the complete Arrow/Paimon static-library closure before reusing the shared prebuilt; otherwise rebuild the selected stack.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Parsed the workflow YAML, checked shell syntax, and exercised missing-header, version-mismatch, missing-library, and exact-match predicate states under bash errexit
- Behavior changed: No
- Does this need documentation: No
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Exact Arrow version and library filenames do not prove that a shared prebuilt contains the selected Paimon source and downstream Arrow/Paimon patches. Scheduled and later BE-only macOS jobs could therefore reuse stale behavior under the same filenames. Generate a deterministic fingerprint from the selected source, patch, cache, and build inputs; record it in extracted sources and installed output; reset stale patched sources; and require the fingerprint plus the complete bundled Brotli/Arrow/Paimon archive closure before reuse.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Parsed workflow and shell syntax, exercised fingerprint reuse and missing-Brotli predicate states, and ran isolated pristine/stale/idempotent Arrow/Paimon patch lifecycle checks
- Behavior changed: No
- Does this need documentation: No
@github-actions github-actions Bot added the approved Indicates a PR has been approved by one committer. label Aug 5, 2026
@hello-stephen

Copy link
Copy Markdown
Contributor

skip check_coverage

@Gabriel39
Gabriel39 merged commit 5baf045 into apache:master Aug 5, 2026
33 of 34 checks passed
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 6, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221, apache#66480

Problem Summary: The Arrow and Paimon prebuilt fingerprints hashed whole shared build scripts. Unrelated differences between master and branch-4.1 therefore rejected a shared prebuilt even when the selected sources, patches, cache, and build recipe were identical. Compute component fingerprints from explicit semantic inputs and schema versions instead. Accept the current master-generated component markers only for the matching new semantic fingerprints, while retaining exact version and artifact-closure validation.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Bash syntax, ShellCheck, shfmt, and git diff checks
    - Local Doris compilation was not run per request
- Behavior changed: No
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 6, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221, apache#66480

Problem Summary: The branch-4.1 BE UT runner uses the install-only thirdparty tree embedded in the shared build image. That image predates the Arrow 24 component closure and does not contain libarrow_compute.a, while the external TeamCity wrapper skips downloading the shared automation prebuilt for branch-4.1. Validate the build-image Arrow/Paimon installation from run-be-ut.sh and refresh it from the shared automation asset when stale. Downloaded archives are validated before replacing the existing installation.

### Release note

None

### Check List (For Author)

- Test: Unit Test
    - bash thirdparty/test/arrow-paimon-lifecycle-test.sh
    - bash -n and shellcheck for the changed shell scripts
    - Full BE compilation was not run for this shell-only CI repair
- Behavior changed: Yes. Linux x86_64 BE UT in the official build image refreshes an incompatible Arrow/Paimon prebuilt before compiling.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 6, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 removed ParquetVersion::PARQUET_2_0, causing the BE UT target to fail while compiling parquet_expr_test.cpp. Use PARQUET_2_6, which is supported by Arrow 24 and matches the other Parquet writer tests.

### Release note

None

### Check List (For Author)

- Test: No local compile or unit test was run per request; build-support/check-format.sh and git diff --check passed.
- Behavior changed: No
- Does this need documentation: No
Gabriel39 pushed a commit that referenced this pull request Aug 6, 2026
…#66480)

### What problem does this PR solve?
bp #66221

Problem Summary: Doris used Apache Arrow 17.0.0, which blocked consuming
newer Arrow fixes and APIs. Upgrade the C++ third-party dependency to
24.0.0, align xsimd with Arrow 24, port the Paimon row-group, INT96, and
Parquet LZO compatibility patches, add Arrow Compute to the static
dependency graph, and migrate removed Arrow and Parquet APIs while
preserving Decimal128 semantics.

### Release note

None

### Check List (For Author)

- Test <!-- At least one of them must be included. -->
    - [ ] Regression test
    - [ ] Unit Test
    - [ ] Manual test (add detailed scripts or steps below)
    - [X] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
        - [x] Previous test can cover this change.
        - [ ] No code files have been changed.
        - [ ] Other reason <!-- Add your reason?  -->

- Behavior changed:
    - [x] No.
    - [ ] Yes. <!-- Explain the behavior change -->

- Does this need documentation?
    - [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
apache/doris-website#1214 -->

### Check List (For Reviewer who merge this PR)

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 7, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: master and branch-4.1 consume the same prebuilt thirdparty prefix. Upgrading the unversioned Arrow/Paimon stack to Arrow 24 makes unchanged branch-4.1 compile against incompatible headers and libraries. Keep Arrow 17/Paimon 17 in the legacy unversioned prefix, install Arrow 24/Paimon 24 in a versioned prefix selected by master, build and validate both source closures independently, and recover only stale stacks.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: built Arrow/Paimon 17 and Arrow/Paimon 24 thirdparty stacks
    - Manual test: ran thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: ran build-support/check-format.sh
    - Partial build check: configured ASAN BE and compiled 13,378 of 14,456 targets without errors before stopping at the user's request
- Behavior changed: Yes. The shared thirdparty prefix keeps Arrow/Paimon 17 at the legacy root and installs master's Arrow/Paimon 24 under a versioned directory.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 8, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: External regression replaces the standard FE configuration with its own fe.conf. That override omitted arrow.adbc.driver.jni.library.path, so the ADBC connector extracted the JNI library bundled in the Maven JAR instead of loading the compatible library built and packaged by Doris thirdparty. On older TeamCity hosts, every Flight SQL catalog case then failed while initializing JniLoader because the bundled library requires newer GLIBC and GLIBCXX versions. Keep the external regression JVM options aligned with the standard FE configuration so it loads output/fe/lib/libadbc_driver_jni.so.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified the JDK 17 option expands arrow.adbc.driver.jni.library.path to the configured DORIS_HOME lib directory
    - Manual test: verified the packaged thirdparty JNI library is present
    - Manual test: git diff --cached --check
- Behavior changed: No. This only corrects the External Regression FE startup configuration.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 11, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The thirdparty GitHub Actions jobs could no longer download the GCC 7 TSAN interface header because gcc.gnu.org now rejects the legacy gitweb URL with HTTP 403. External Regression also compared DBL_MAX through the test client, where Arrow 24 preserves the finite 17-digit value while the existing 16-digit baseline parses above DBL_MAX as infinity. Pin the unchanged TSAN header to the GCC GitHub mirror and explicitly format the ADBC display baseline to 16 significant digits while retaining the bit-for-bit in-Doris value comparison.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: thirdparty/download-thirdparty.sh tsan_header
    - Manual test: bash -n thirdparty/vars.sh
    - Manual test: verified format("{:.16g}", value) output for all non-null DOUBLE fixture values
    - Manual test: git diff --cached --check
- Behavior changed: No. The changes only restore CI downloads and stabilize an existing regression baseline.
- Does this need documentation: No
wyxxxcat pushed a commit to wyxxxcat/doris that referenced this pull request Aug 17, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: Doris used Apache Arrow 17.0.0, which blocked consuming
newer Arrow fixes and APIs. Upgrade the C++ third-party dependency to
24.0.0, align xsimd with Arrow 24, port the Paimon row-group, INT96, and
Parquet LZO compatibility patches, add Arrow Compute to the static
dependency graph, and migrate removed Arrow and Parquet APIs while
preserving Decimal128 semantics.

### Release note

None

### Check List (For Author)

- Test <!-- At least one of them must be included. -->
    - [ ] Regression test
    - [ ] Unit Test
    - [ ] Manual test (add detailed scripts or steps below)
    - [X] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
        - [x] Previous test can cover this change.
        - [ ] No code files have been changed.
        - [ ] Other reason <!-- Add your reason?  -->

- Behavior changed:
    - [x] No.
    - [ ] Yes. <!-- Explain the behavior change -->

- Does this need documentation?
    - [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
apache/doris-website#1214 -->

### Check List (For Reviewer who merge this PR)

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 24, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: master and pre-upgrade branch-4.1 revisions consume the same prebuilt thirdparty package. Upgrading the unversioned Arrow/Paimon stack to Arrow 24 makes unchanged branch-4.1 code compile against incompatible headers and libraries. Keep Arrow 17/Paimon 17 in the legacy unversioned prefix, install Arrow 24/Paimon 24 in a versioned prefix selected by master, build and validate both source closures independently, and recover only stale stacks.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: downloaded and checksum-verified the latest Linux x86_64 thirdparty prebuilt
    - Manual test: built Arrow/Paimon 17 and Arrow/Paimon 24 thirdparty stacks
    - Manual test: ran thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: completed an ASAN master BE and FE build
- Behavior changed: Yes. The shared thirdparty prefix keeps Arrow/Paimon 17 at the legacy root and installs the Arrow/Paimon 24 stack selected by master under a versioned directory.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 24, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: External regression replaces the standard FE configuration with its own fe.conf. That override omitted arrow.adbc.driver.jni.library.path, so the ADBC connector extracted the JNI library bundled in the Maven JAR instead of loading the compatible library built and packaged by Doris thirdparty. On older TeamCity hosts, every Flight SQL catalog case then failed while initializing JniLoader because the bundled library requires newer GLIBC and GLIBCXX versions. Keep the external regression JVM options aligned with the standard FE configuration so it loads output/fe/lib/libadbc_driver_jni.so.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified the JDK 17 option expands arrow.adbc.driver.jni.library.path to the configured DORIS_HOME lib directory
    - Manual test: verified the packaged thirdparty JNI library is present
    - Manual test: git diff --cached --check
- Behavior changed: No. This only corrects the External Regression FE startup configuration.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 24, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 preserves DBL_MAX as a finite 17-digit value, while the existing ADBC regression baseline is intentionally rendered with 16 significant digits. Passing the 17-digit text through the test client can reparse it above DBL_MAX as infinity. Explicitly format the displayed DOUBLE column to 16 significant digits while retaining the existing bit-for-bit value comparison inside Doris.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified format("{:.16g}", value) output for every non-null DOUBLE fixture value
    - Manual test: git diff --check for this commit
- Behavior changed: No. This only stabilizes an existing external regression baseline.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 27, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: master and pre-upgrade branch-4.1 revisions consume the same prebuilt thirdparty package. Upgrading the unversioned Arrow/Paimon stack to Arrow 24 makes unchanged branch-4.1 code compile against incompatible headers and libraries. Keep Arrow 17/Paimon 17 in the legacy unversioned prefix, install Arrow 24/Paimon 24 in a versioned prefix selected by master, build and validate both source closures independently, and recover only stale stacks.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: downloaded and checksum-verified the latest Linux x86_64 thirdparty prebuilt
    - Manual test: built Arrow/Paimon 17 and Arrow/Paimon 24 thirdparty stacks
    - Manual test: ran thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: completed an ASAN master BE and FE build
- Behavior changed: Yes. The shared thirdparty prefix keeps Arrow/Paimon 17 at the legacy root and installs the Arrow/Paimon 24 stack selected by master under a versioned directory.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 27, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: External regression replaces the standard FE configuration with its own fe.conf. That override omitted arrow.adbc.driver.jni.library.path, so the ADBC connector extracted the JNI library bundled in the Maven JAR instead of loading the compatible library built and packaged by Doris thirdparty. On older TeamCity hosts, every Flight SQL catalog case then failed while initializing JniLoader because the bundled library requires newer GLIBC and GLIBCXX versions. Keep the external regression JVM options aligned with the standard FE configuration so it loads output/fe/lib/libadbc_driver_jni.so.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified the JDK 17 option expands arrow.adbc.driver.jni.library.path to the configured DORIS_HOME lib directory
    - Manual test: verified the packaged thirdparty JNI library is present
    - Manual test: git diff --cached --check
- Behavior changed: No. This only corrects the External Regression FE startup configuration.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 27, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 preserves DBL_MAX as a finite 17-digit value, while the existing ADBC regression baseline is intentionally rendered with 16 significant digits. Passing the 17-digit text through the test client can reparse it above DBL_MAX as infinity. Explicitly format the displayed DOUBLE column to 16 significant digits while retaining the existing bit-for-bit value comparison inside Doris.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified format("{:.16g}", value) output for every non-null DOUBLE fixture value
    - Manual test: git diff --check for this commit
- Behavior changed: No. This only stabilizes an existing external regression baseline.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 27, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Review found that reused CMake caches could retain stale automatic Arrow/Paimon prefixes, build.sh validated the shared default even when CMake selected another pair, an interrupted root-prefix Arrow 17 migration could expose Paimon built against Arrow 24, and target normalization incorrectly gated Cloud-only and standalone compile-bench builds. Refresh CMake selections on every configure, reject unsupported build.sh prefix overrides before recovery, remove Paimon before downgrading the legacy Arrow prefix, and normalize dependency consumers before preflight. The PR no longer modifies the macOS BE workflow because upstream intentionally removed PR triggers and the existing thirdparty workflow already validates both macOS builds.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: bash -n for the modified build and lifecycle scripts
    - Manual test: thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: git diff --cached --check
- Behavior changed: Yes. Cloud-only builds skip unused Arrow/Paimon validation, standalone compile-bench performs BE preflight, unsupported explicit build.sh prefixes fail clearly, and interrupted Arrow 17 migration removes ABI-incompatible Paimon artifacts first.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 28, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: master and pre-upgrade branch-4.1 revisions consume the same prebuilt thirdparty package. Upgrading the unversioned Arrow/Paimon stack to Arrow 24 makes unchanged branch-4.1 code compile against incompatible headers and libraries. Keep Arrow 17/Paimon 17 in the legacy unversioned prefix, install Arrow 24/Paimon 24 in a versioned prefix selected by master, build and validate both source closures independently, and recover only stale stacks.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: downloaded and checksum-verified the latest Linux x86_64 thirdparty prebuilt
    - Manual test: built Arrow/Paimon 17 and Arrow/Paimon 24 thirdparty stacks
    - Manual test: ran thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: completed an ASAN master BE and FE build
- Behavior changed: Yes. The shared thirdparty prefix keeps Arrow/Paimon 17 at the legacy root and installs the Arrow/Paimon 24 stack selected by master under a versioned directory.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 28, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Arrow 24 preserves DBL_MAX as a finite 17-digit value, while the existing ADBC regression baseline is intentionally rendered with 16 significant digits. Passing the 17-digit text through the test client can reparse it above DBL_MAX as infinity. Explicitly format the displayed DOUBLE column to 16 significant digits while retaining the existing bit-for-bit value comparison inside Doris.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: verified format("{:.16g}", value) output for every non-null DOUBLE fixture value
    - Manual test: git diff --check for this commit
- Behavior changed: No. This only stabilizes an existing external regression baseline.
- Does this need documentation: No
hubgeter added a commit to hubgeter/doris that referenced this pull request Aug 28, 2026
### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: Review found that reused CMake caches could retain stale automatic Arrow/Paimon prefixes, build.sh validated the shared default even when CMake selected another pair, an interrupted root-prefix Arrow 17 migration could expose Paimon built against Arrow 24, and target normalization incorrectly gated Cloud-only and standalone compile-bench builds. Refresh CMake selections on every configure, reject unsupported build.sh prefix overrides before recovery, remove Paimon before downgrading the legacy Arrow prefix, and normalize dependency consumers before preflight. The PR no longer modifies the macOS BE workflow because upstream intentionally removed PR triggers and the existing thirdparty workflow already validates both macOS builds.

### Release note

None

### Check List (For Author)

- Test:
    - Manual test: bash -n for the modified build and lifecycle scripts
    - Manual test: thirdparty/test/arrow-paimon-lifecycle-test.sh
    - Manual test: git diff --cached --check
- Behavior changed: Yes. Cloud-only builds skip unused Arrow/Paimon validation, standalone compile-bench performs BE preflight, unsupported explicit build.sh prefixes fail clearly, and interrupted Arrow 17 migration removes ABI-incompatible Paimon artifacts first.
- Does this need documentation: No
buu-nguyen pushed a commit to thealtoclef/doris that referenced this pull request Aug 28, 2026
The iceberg table-function schema converter called the generic
arrow::decimal() factory, which the bundled Arrow headers no longer provide
(DecimalType is now backed by the typed decimal128()/decimal256() forms), so
source builds of the BE failed in be/src/format/table/iceberg/arrow_schema_util.cpp.
Switch to arrow::decimal128() — ICEBERG decimals are always 128-bit.

Hunk picked from the upstream Apache Arrow 24.0.0 thirdparty upgrade:

  branch-4.1  f0e0080  [chore](thirdparty) Upgrade Apache Arrow to 24.0.0 (apache#66480)
              (backport of main 5baf045 / PR apache#66221)

Only this single API-migration line is taken; the full Arrow 17 -> 24
thirdparty bump is NOT part of this commit and 4.1.3 still pins Arrow 17.0.0.
On a stock thirdparty build (Arrow 17) arrow::decimal() still exists, so this
hunk is only required for source builds against newer bundled Arrow headers;
decimal128() itself exists in both versions, making it safe either way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Gabriel39 pushed a commit that referenced this pull request Aug 31, 2026
### What problem does this PR solve?

Related PR: #66221

Problem Summary: master and branch-4.1 consume the same prebuilt
thirdparty prefix. Upgrading the unversioned Arrow/Paimon stack to Arrow
24 makes unchanged branch-4.1 compile against incompatible headers and
libraries. Keep Arrow 17/Paimon 17 in the legacy unversioned prefix,
install Arrow 24/Paimon 24 in a versioned prefix selected by master,
build and validate both source closures independently, and recover only
stale stacks.

### Release note

None

### Check List (For Author)

- Test <!-- At least one of them must be included. -->
    - [ ] Regression test
    - [ ] Unit Test
    - [ ] Manual test (add detailed scripts or steps below)
    - [x] No need to test or manual test. Explain why:
- [ ] This is a refactor/code format and no logic has been changed.
        - [x] Previous test can cover this change.
        - [ ] No code files have been changed.
        - [ ] Other reason <!-- Add your reason?  -->

- Behavior changed:
    - [ ] No.
    - [x] Yes. <!-- Explain the behavior change -->

- Does this need documentation?
    - [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
apache/doris-website#1214 -->

### Check List (For Reviewer who merge this PR)

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label <!-- Add branch pick label that this PR
should merge into -->
hubgeter added a commit to hubgeter/doris that referenced this pull request Sep 2, 2026
…orkflow

### What problem does this PR solve?

Issue Number: None

Related PR: apache#66221

Problem Summary: The Arrow 24 upgrade introduced an Arrow/Paimon-specific semantic-fingerprint system, legacy marker allowlists, installed-artifact validators, focused recovery paths, and dedicated lifecycle CI. This diverged from the standard Doris thirdparty workflow and made dependency maintenance unnecessarily complex. Follow the existing model used by other dependency upgrades: keep source versions and checksums in vars.sh, use patch markers for source preparation, rely on matching thirdparty prebuilts, and use the existing platform completion sentinel to trigger a full rebuild. Remove the special fingerprint and macOS recovery paths while preserving the Arrow 24/Compute/Paimon build changes, bundled xsimd/Brotli source closure, and later ADBC/Paimon configuration tests.

### Release note

None

### Check List (For Author)

- Test: Manual test
    - Bash syntax checks for all changed shell scripts
    - YAML parsing for the changed GitHub workflows
    - Thirdparty download, checksum, Azure retry, ADBC, and Paimon codec tests
    - Clean Arrow/Paimon/xsimd/Brotli download and patch application
    - Repeated download for idempotence and Paimon patch-marker migration
    - ShellCheck with error severity and git diff --check
    - Full thirdparty compilation was not run
- Behavior changed: Yes. Arrow/Paimon now follow the standard matching-prebuilt and full-rebuild thirdparty workflow instead of dedicated installed fingerprints and focused recovery.
- Does this need documentation: No
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by one committer. dev/4.1.x dev/4.1.x-conflict

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants