DanielLeens commented on PR #10849:
URL: https://github.com/apache/seatunnel/pull/10849#issuecomment-4538714225

   Thanks for the follow-up. I re-reviewed the latest head from scratch, 
including the new merge-dev / registration commit, and I do not see a reopened 
Bigtable source/sink blocker on the current code revision.
   
   # What this PR fixes
   - User pain: the Bigtable connector needed its source/sink path, recovery 
behavior, save-mode guard, and connector registration to converge to a usable 
first version.
   - Fix approach: the earlier source/sink fixes remain in place, and the 
latest head mainly refreshes the branch against dev and completes registration.
   - One-line summary: the Bigtable production path still looks healthy; the 
remaining gate is the final Build signal, not a reopened connector bug.
   
   # Runtime chain I checked
   ~~~text
   Bigtable source
     -> BigtableSourceReader.open()
     -> pollNext() sets currentSplit and streams readRows(...).forEach(...)
     -> snapshotState() still preserves the in-flight split
   
   Bigtable sink
     -> BigtableSink.createWriter()
     -> handleSaveMode()
     -> BigtableSinkWriter batch write path
   
   Latest delta
     -> merge dev / registration completion
     -> no reopened issue on the Bigtable runtime path
   ~~~
   
   # Findings
   - No new blocking source-level issue found on the Bigtable connector itself.
   
   # CI note
   - The branch is now mergeable, so the earlier conflict blocker is gone.
   - The current Build is still red on programmerloverun/seatunnel run 
26401523768.
   - The failing lanes are broad (for example kafka-connector-it, 
all-connectors-it-5, connector-file-sftp, all-connectors-it-1), so the latest 
head still lacks a final green merge signal.
   
   # Merge conclusion
   ### Conclusion: can merge after fixes
   
   1. Blocking items
   - Please get the current mergeable head green in CI before merging.
   
   2. Suggested non-blocking follow-up
   - After CI is green, an extra focused Bigtable regression test would still 
be nice, but I do not see that as the main blocker right now.
   
   Overall, the Bigtable implementation looks close to done. The remaining work 
is branch hygiene and CI closure, not a new runtime rewrite.
   


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