DanielLeens commented on PR #10938:
URL: https://github.com/apache/seatunnel/pull/10938#issuecomment-4538714912
Thanks for the update. I re-reviewed the latest head from scratch. The
source-level blocker I raised earlier around overloading max_retries as the
Bulk job completion cap is resolved on the current revision.
# What this PR fixes
- User pain: the first Salesforce source version needs to keep Bulk API job
waiting semantics separate from HTTP retry semantics.
- Fix approach: the latest head introduces job_completion_timeout_ms and
uses that dedicated timeout in waitForJobCompletion().
- One-line summary: the current source path looks much healthier now; the
remaining gate is CI, not a reopened Salesforce runtime bug.
# Runtime chain I checked
~~~text
Salesforce source path
-> create bulk query job
-> waitForJobCompletion(jobId) in SalesforceClient.java:237-266
-> total wait window now comes from jobCompletionTimeoutMs
-> downloadResults(...) still streams CSV pages row by row
~~~
# Findings
- No new blocking source-level issue found on the current head.
# CI note
- The current Build is still red on NixonWahome/seatunnel run 26411285175.
- The failing lanes I traced are unit-test (8), all-connectors-it-5, and
engine-v2-it. They do not point directly to the Salesforce source path, but the
branch still lacks a final green merge signal.
# Merge conclusion
### Conclusion: can merge after fixes
1. Blocking items
- Please get the latest Build green first.
2. Suggested non-blocking follow-up
- No additional source-level follow-up blocker from my side on the
Salesforce path.
Overall, the current head resolves the earlier runtime blocker and looks
close to done from the code-review side. The remaining gate is CI closure.
--
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]
