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]