morningman opened a new pull request, #66468:
URL: https://github.com/apache/doris/pull/66468
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #64822 (backported here), #64945 / #65209 (plugin wait behavior
aligned to master)
Problem Summary:
Triage of a chronically red branch-4.0 P2 regression pipeline run (7
failures, no BE
crash/OOM — all case-level). Root causes were identified from build logs, BE
compaction
status dumps and FE code; this PR fixes all of them (1 FE product bug + 5
test/CI fixes):
1. **[load] Broker load pending-task retry self-conflicts on its own label**
(FE product bug,
also present on master). `BrokerLoadPendingTask.executeTask()` runs
`getAllFileStatus()`
then `beginTxn()`, and `LoadTask.exec` retries the whole task on failure
(retryTime=3).
If the first attempt registers the txn but throws before `transactionId`
is assigned
(observed: `beginTransaction` failing on the edit-log write when the FE
meta disk hit
ENOSPC), every retry hits `LabelAlreadyUsedException` against the job's
OWN PREPARE txn,
burns all retries within seconds and cancels the job with a misleading
`Label [...] has already been used, relate to txn [...], status
[PREPARE]`.
Fix: make `beginTxn()` retry-idempotent — reuse an already-assigned
`transactionId`, and
on `LabelAlreadyUsedException` adopt the label's txn iff it is ours
(`callbackId == job id` and status PREPARE). Foreign conflicts and lookup
failures still
rethrow the original exception. Adds 3 JMockit unit tests.
2. **plugin_compaction.groovy**: (a) treat base compaction's `E-808`
(`BE_NO_SUITABLE_VERSION`, the by-design "nothing to base-compact" result
from
`BaseCompaction::pick_rowsets_to_compact`) as benign, exactly like
cumulative's
E-2000/E-2010 — a lagging publish can legitimately make one replica's
cumulative a no-op
so its later base trigger has nothing to merge; (b) port master's
failure-time-aware wait
(#64945/#65209) so a compaction that FAILS on the BE ends the wait within
one poll
interval instead of idling the full timeout (observed: 40min hang after
an ENOSPC'd
cumulative).
3. **compaction_width_array_column**: with `BUCKETS 2` the fixture loads a
~56GB
197-segment overlapping rowset into a single tablet; compaction writes
the full output on
the same mount before deleting the input, which structurally ENOSPCs on
100GB CI data
disks (11/11 recent runs red; ASAN runs hit MEM_LIMIT for the same
oversize). Bump to
`BUCKETS 16` (~7GB/tablet). Also align the load properties (16G
exec_mem_limit,
load_parallelism 1) that already de-flaked the load phase on branch-4.0.
4. **inverted_index_p2/test_show_data**: all four sub-suites compare
physical index sizes
produced by different writer paths (inline-at-load vs ALTER+BUILD INDEX vs
index-compaction merge vs rebuild). Settle-sequence analysis shows the
values are stable
per run yet differ by a fixed per-index-file overhead (~7KB per replica,
12-15% relative
on the httplogs fixture), so exact equality flakes chronically (6/11,
6/11, 3/11, 4/11
recent runs across the four sub-suites). Replace exact equality with 20%
tolerance — a
missing index still shows as a ~37% deficit and real bloat as 2x+.
Pure-data
(`no_index_size`) exact compares are kept.
5. **cold_heat_separation_p2/table_modify_resouce_and_policy(+_by_hdfs)**:
both phases
waited only for `tablets[0]` to finish cooldown, then asserted
`remote_data_size > 0`
for EVERY replica row. Replicated cooldown is
leader-uploads/followers-follow-async, so a
lagging follower failed the assert with zero grace (7/11 recent runs).
Make the wait
cover all replica rows (local==0 && remote>0) with the same 100x10s
budget.
6. **datatype_p2/two_level_nestedtypes_with_s3data**: backport #64822 — the
s3() smoke
query selected nested complex columns with `order by k1 limit 10`;
duplicate k1 values at
the limit boundary make the selected rows nondeterministic. branch-4.0
had backported
#64706 but missed this follow-up. All 3 files are byte-identical to
master after this.
### Release note
None
### Check List (For Author)
- Test <!-- At least one of them must be included. -->
- [x] 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 <!-- Add your reason? -->
- Behavior changed:
- [ ] No.
- [x] Yes. Broker load jobs whose pending task is retried after the
job's txn was
already begun/registered now reuse (or adopt) that txn instead of
being cancelled
with a misleading "Label has already been used" error. No behavior
change outside
that failure path.
- Does this need documentation?
- [x] No.
- [ ] Yes. <!-- Add document PR link here. eg:
https://github.com/apache/doris-website/pull/1214 -->
Verification: `mvn test -pl fe-core -am` (build cache disabled) —
`BrokerLoadJobTest`
13/13 green (10 existing + 3 new), 0 checkstyle violations; all changed
groovy files pass
offline `FileSystemCompiler` syntax check; backported #64822 files are
blob-identical to
master.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
