zhang-arvin commented on PR #9535:
URL: https://github.com/apache/paimon/pull/9535#issuecomment-5574158766

   Thanks @JingsongLi and @lilei1128 for the review, and sorry for the slow 
turnaround.
   
   On the pending-splits / sink-writer state concern (@lilei1128): agreed that 
the fix here is deliberately source-side and minimal. It targets the observed 
deadlock only — the restored `nextSnapshotId` is already below 
`earliestSnapshotId`, so the scan loops on `SnapshotNotExistPlan` and never 
advances. Falling back to the starting scanner lets 
`ContinuousCompactorStartingScanner` resume from the latest compact snapshot, 
which is safe since compaction is idempotent. You're right that a checkpoint 
can carry pending splits referencing expired snapshots, and that the read-time 
race you described (snapshot expiring between plan and read) is real and 
independent of this deadlock: both belong in the discard-expired-splits / 
rebuild-writer-state recovery story you outlined. That touches the split 
enumerator and writer state, which this PR intentionally doesn't touch, so I'll 
keep this PR scoped to the restore fix and file a follow-up issue for the 
pending-splits cleanup + end-to-end reco
 very protocol, linking it here.
   
   On the Spark test failure (@JingsongLi): I've been looking at the CI logs. 
In the latest run the core/Flink jobs are green; the failure comes from 
`PaimonMicroBatchStreamITCase` — "resume consumer from long-lived changelog 
after snapshot expiration" — an NPE inside the `failAfter` block at line 331, 
where `latestOffset` returned null. It only reproduces in the Scala 2.13 
`build_test` jobs (1.20 / 2.2 / 2.12 pass; one 2.13 job is cancelled). That 
test isn't part of this PR's diff, but it hits the same snapshot-expiration 
territory: a consumer resuming from an expired snapshot backed by a long-lived 
changelog. I'm checking whether the new fallback (which fires whenever the 
restored snapshot is already expired) is redirecting that consumer resume into 
the starting-scanner path, and whether the failure reproduces on master without 
this change. I'll report back here with the root cause and either scope the 
fallback or fix the test accordingly.


-- 
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]

Reply via email to