)

Related PR: #65196

Problem Summary:
A rollup job in WAITING_TXN checks and aborts failed conflict
transactions before proceeding. If a transaction is already committed,
becomes visible, or is cleaned up before the abort completes,
abortTransaction() can throw UserException. RollupJobV2 propagates this
as AlterCancelException, causing the entire rollup job to be cancelled.
Restarting FE with committed but not yet visible transactions reproduces
this failure (the txn_insert_restart_fe_with_schema_change regression
case can produce this bug).

Apply the retry behavior introduced for schema change in #65196 to
rollup jobs: log the abort failure, keep the job in WAITING_TXN, and
re-query transaction state in the next scheduler round. Also exclude
committed and final transactions from the shared failed-transaction
selector to avoid unnecessary abort attempts.

…failure (#67661) (#68055)

Cherry-picked from #67661

…failure (#67661) (#68055)

Cherry-picked from #67661

)

### What problem does this PR solve?

Issue Number: close #68755

Related PR: #65196, #67661, #67761

Problem Summary:

In Apache Doris 4.1.3, a cloud stream-load transaction can remain
PREPARE after its coordinator BE is restarted or rescheduled. With FQDN
addressing, the registered backend hostname differs from the recorded
client IP; after rescheduling, the pod IP can also change. FE failure
detection and meta-service coordinator cleanup then miss the abandoned
transaction, leaving schema changes and rollups in WAITING_TXN until
expiration or manual abort.

This PR targets master and uses the backend ID when both coordinator IDs
are nonzero, falling back to address matching when either ID is unknown.
The cloud FE checks restart/liveness after backend lookup by ID without
requiring hostname/IP equality. Startup-time and transaction-status
filters remain in place, and non-cloud FE address matching is preserved.

Master already contains the schema-change/rollup retry and
committed/final-status safeguards from #65196 and #67661. This PR
complements those changes and preserves the scan/retry behavior from
#67761.

Tests added cover cloud restart and lost-heartbeat detection with
differing addresses, protection of the current process/recent heartbeat,
non-cloud compatibility, changed-address lookup on both meta-service
scan paths, startup-time filtering, different known IDs sharing an
address, unknown request-ID fallback, and changed-address abort with
current-process protection.

Validation:

- On this master-based patch: Java Checkstyle passed for both changed
Java files; changed C++ files were formatted with clang-format 16.0.6;
`git diff --check` passed.
- Source-extracted compiled checks on this patch passed 33 FE
failure-detection cases and 54 identity cases for each of the two
meta-service matching expressions. These checks are isolated harnesses,
not the project's native unit-test suites.
- Earlier Docker validation for the 4.1.3 fix passed
`AlterTxnRecoveryTest` (4 tests) and `CloudIndexTest`,
`SchemaChangeJobV2Test`, `RollupJobV2Test`, and
`GlobalTransactionMgrTest` (37 tests total). These results do not
validate this master PR head.
- The earlier full FE Docker run is still in progress. Two failures have
been observed in `AuthenticationPluginManagerTest` concerning OIDC
factory/plugin loading. The run uses `maven.test.failure.ignore=true` to
collect failures across modules; a successful Maven exit must not be
interpreted as a passing suite.
- Native execution of the new master-based FE and cloud tests,
full-suite validation of this PR head, and a cloud BE-rescheduling
end-to-end reproduction are pending. No successful result is claimed for
them.

CI / review follow-up: request CI workflow approval from a Committer,
then trigger `run buildall` for the current PR head according to the
project's review-and-CI guide. Cloud/meta-service Code Owner review is
required. This PR is ready for code review; pending validation and
required approvals must be resolved before merge.

### Release note

Fix cloud transaction cleanup missing restarted or rescheduled BE
coordinators when their address changes or FQDN addressing is used,
which could leave schema changes and rollups waiting for abandoned
prepared transactions.

### Check List (For Author)

- Test
    - [ ] Regression test
    - [x] 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.
- [x] Yes. Cloud cleanup matches known backend IDs despite address
changes; unknown IDs fall back to address matching.

- Does this need documentation?
    - [x] 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: close #68755

Related PR: #65196, #67661, #67761

Problem Summary:

In Apache Doris 4.1.3, a cloud stream-load transaction can remain
PREPARE after its coordinator BE is restarted or rescheduled. With FQDN
addressing, the registered backend hostname differs from the recorded
client IP; after rescheduling, the pod IP can also change. FE failure
detection and meta-service coordinator cleanup then miss the abandoned
transaction, leaving schema changes and rollups in WAITING_TXN until
expiration or manual abort.

This PR targets master and uses the backend ID when both coordinator IDs
are nonzero, falling back to address matching when either ID is unknown.
The cloud FE checks restart/liveness after backend lookup by ID without
requiring hostname/IP equality. Startup-time and transaction-status
filters remain in place, and non-cloud FE address matching is preserved.

Master already contains the schema-change/rollup retry and
committed/final-status safeguards from #65196 and #67661. This PR
complements those changes and preserves the scan/retry behavior from
#67761.

Tests added cover cloud restart and lost-heartbeat detection with
differing addresses, protection of the current process/recent heartbeat,
non-cloud compatibility, changed-address lookup on both meta-service
scan paths, startup-time filtering, different known IDs sharing an
address, unknown request-ID fallback, and changed-address abort with
current-process protection.

Validation:

- On this master-based patch: Java Checkstyle passed for both changed
Java files; changed C++ files were formatted with clang-format 16.0.6;
`git diff --check` passed.
- Source-extracted compiled checks on this patch passed 33 FE
failure-detection cases and 54 identity cases for each of the two
meta-service matching expressions. These checks are isolated harnesses,
not the project's native unit-test suites.
- Earlier Docker validation for the 4.1.3 fix passed
`AlterTxnRecoveryTest` (4 tests) and `CloudIndexTest`,
`SchemaChangeJobV2Test`, `RollupJobV2Test`, and
`GlobalTransactionMgrTest` (37 tests total). These results do not
validate this master PR head.
- The earlier full FE Docker run is still in progress. Two failures have
been observed in `AuthenticationPluginManagerTest` concerning OIDC
factory/plugin loading. The run uses `maven.test.failure.ignore=true` to
collect failures across modules; a successful Maven exit must not be
interpreted as a passing suite.
- Native execution of the new master-based FE and cloud tests,
full-suite validation of this PR head, and a cloud BE-rescheduling
end-to-end reproduction are pending. No successful result is claimed for
them.

CI / review follow-up: request CI workflow approval from a Committer,
then trigger `run buildall` for the current PR head according to the
project's review-and-CI guide. Cloud/meta-service Code Owner review is
required. This PR is ready for code review; pending validation and
required approvals must be resolved before merge.

### Release note

Fix cloud transaction cleanup missing restarted or rescheduled BE
coordinators when their address changes or FQDN addressing is used,
which could leave schema changes and rollups waiting for abandoned
prepared transactions.

### Check List (For Author)

- Test
    - [ ] Regression test
    - [x] 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.
- [x] Yes. Cloud cleanup matches known backend IDs despite address
changes; unknown IDs fall back to address matching.

- Does this need documentation?
    - [x] No.
    - [ ] Yes.

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

- [ ] Confirm the release note
- [ ] Confirm test cases
- [ ] Confirm document
- [ ] Add branch pick label