Skip to content

[ENG-41301] Fix V9 batcher dropping all batches when savepoint shares instant time with deltacommit - #187

Merged
tiennguyen-onehouse merged 2 commits into
mainfrom
fix-batcher-savepoint-interleave
Jun 5, 2026
Merged

[ENG-41301] Fix V9 batcher dropping all batches when savepoint shares instant time with deltacommit#187
tiennguyen-onehouse merged 2 commits into
mainfrom
fix-batcher-savepoint-interleave

Conversation

@tiennguyen-onehouse

@tiennguyen-onehouse tiennguyen-onehouse commented May 5, 2026

Copy link
Copy Markdown
Contributor

Summary

  • For V9/V2 tables with daily-savepoint workloads (e.g. Concentric perf), ActiveTimelineInstantBatcher.createBatches was returning zero batches and silently halting upload of the active timeline.
  • The fix peels a savepoint's two files into their own batch — but only when the savepoint shares an instant time with a non-savepoint commit (the case that breaks triplet matching). Savepoints at their own unique instant time keep the existing inline, instant-time-ordered path, so prior behavior is preserved.

Root cause

A savepoint pinned to instant time T writes <T>.savepoint.inflight + <T>_<completionTs>.savepoint. When a deltacommit also exists at the same T, after lex-sort the files interleave:

1. <T>.deltacommit.inflight
2. <T>.deltacommit.requested
3. <T>.savepoint.inflight      <- intruder
4. <T>_<ct>.deltacommit
5. <T>_<ct>.savepoint

Two things break:

  1. The deltacommit triplet is corrupted — the loop checks files 1–3 expecting {inflight, requested, completed} but gets {inflight, requested, inflight}. With the default upload strategy this trips shouldStopIteration=true at the very first group, producing zero batches.
  2. The savepoint's own two files are no longer adjacent (positions 3 and 5, split by the deltacommit's completed file at 4), so the inline 2-file savepoint pairing can't group them either.

The bug is silent (logged only at INFO: Could not create batches with completed commits…).

Confirmed in staging by cloning Concentric's lhperftest/.../permissions_bronze/.hoodie/ (5 daily savepoint groups + 1 compaction-with-savepoint) and observing the looping INFO log every poll cycle with no progress.

Fix

extractSavepointPairs records the instant times of all non-savepoint files, then peels a complete savepoint pair (inflight + completed) into its own 2-file batch only when its timestamp collides with a non-savepoint instant. This:

Non-colliding savepoints and partial savepoints (only inflight or only completed) stay in the list and are processed by the existing inline savepoint path, unchanged. Colliding savepoint batches are appended after the commit batches (safe — savepoints carry no write metadata).

Test plan

  • Existing ActiveTimelineInstantBatcherTest cases still pass (V1 layout / no savepoints).
  • Existing V9 tests still pass.
  • Added testCreateBatchWithV9SavepointSharingInstantTimeWithDeltacommit, modelled on permissions_bronze's timeline (daily deltacommit+savepoint sharing instant time): reproduces the zero-batches bug and asserts the deltacommit triplets batch cleanly with the savepoint pairs appended. Suite now 25 tests / 0 failures.
  • CI build green (build + SonarCloud).
  • Re-run the staging clone of permissions_bronze and observe Uploading batch … logs progressing past April 30. (manual staging step)

Related

  • ENG-41301 — Concentric Lakeview v9 stats missing / 500
  • gateway-controller PR #9103 (read-side fixes for the lifecycle sentinel rows that surface from the same incident)

🤖 Generated with Claude Code

… instant time with deltacommit

In Hudi V2 / table-version-9 layout a savepoint pinned to an instant time T
produces five files at the same T:

  <T>.deltacommit.inflight
  <T>.deltacommit.requested
  <T>.savepoint.inflight
  <T>_<completionA>.deltacommit
  <T>_<completionB>.savepoint

After lex-sort, <T>.savepoint.inflight lands at position 3 of the same-T
deltacommit's group, breaking the (inflight, requested, completed) triplet
check in createBatches: the third file is a savepoint inflight, so states
become {inflight, requested, inflight} instead of the expected superset of
{inflight, requested, completed}. With the default upload strategy this
sets shouldStopIteration=true at the very first group, returning zero
batches and silently halting upload of the entire active timeline. The
extractor logs only the INFO "Could not create batches with completed
commits" each cycle, so the table never advances.

Fix: pre-extract complete savepoint pairs (one inflight + one completed at
the same T) into their own 2-file batches before the triplet loop runs,
restoring the deltacommit/commit triplet to a clean three-file group at
that T. Partial savepoints (single file) stay in the main flow so the
existing single-savepoint handling can still process them. Savepoint
batches are appended after commit batches; savepoints carry no write
metadata so this ordering is benign.

Reproduction: any V9 MoR table that runs daily savepoints (e.g. the
Concentric perf-test workload). After this fix LakeView resumes uploading
post-savepoint instants — including any compaction the customer triggers
once log files accumulate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@nimahajan

Copy link
Copy Markdown

@tiennguyen-onehouse tiennguyen-onehouse left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

/push-image hudi1.1-May5

Preliminary review found the original fix moved ALL complete savepoint
pairs to the end of the batch list, which reordered non-colliding
savepoints and broke two existing tests
(testCreateBatchWithCommitAndSavepointAsMiddletBatchActions,
testIncompleteLastAction).

Gate extraction on collision: a savepoint pair is peeled into its own
batch only when it shares an instant time with a non-savepoint commit —
the actual V9 case that breaks triplet matching. Savepoints at their own
unique instant time keep the existing inline, instant-time-ordered path,
so prior behavior is preserved.

Add testCreateBatchWithV9SavepointSharingInstantTimeWithDeltacommit
modeling permissions_bronze's daily-savepoint timeline: reproduces the
zero-batches bug and asserts the deltacommit triplets batch cleanly with
the savepoint pairs appended after.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@sonarqubecloud

sonarqubecloud Bot commented Jun 5, 2026

Copy link
Copy Markdown

@tiennguyen-onehouse
tiennguyen-onehouse merged commit 3275c3f into main Jun 5, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants