DanielLeens commented on PR #11648:
URL: https://github.com/apache/seatunnel/pull/11648#issuecomment-5287981340
Verified this directly against the diff rather than taking the write-up on
faith, since it landed after my last comment.
**What changed.** `9ae57a54035136a60ae6f739870fbab21083d894` is a real new
commit on top of the head I last reviewed (`5256b12f...`), and it is exactly
what it claims to be: 10 files, all under `docs/`, nothing else. `git diff
--name-only` between the previous commit and this one shows zero files outside
`docs/en` and `docs/zh` — no pom, no Java, no shade config touched. That means
every piece of the technical work from my earlier rounds
(Hadoop/hadoop-aws/hadoop-aliyun lockstep, reload4j exclusion, the AWS-service
allowlist filter, the S3A/OSS E2E harness fixes, the AWS SDK v2 thread
allowlist, the okio relocation) is untouched and still stands on its own prior
verification.
**The fix itself, checked line by line:**
1. `docs/{en,zh}/connectors/{sink,source}/OssFile.md` — the Zeta-engine jar
list now reads `aliyun-sdk-oss-3.13.2.jar`, `hadoop-aliyun-3.4.3.jar`,
`jdom2-2.0.6.1.jar` (previously stale at `3.4.1`/`3.1.4`/`jdom-1.1.jar`), with
a new blockquote explaining why the three have to move together — same
`ListObjectsV2Request`/`ListObjectsV2Result`/`VoidResult` reasoning from your
earlier comment, correctly reproduced. This closes the exact
silent-runtime-failure gap I raised: a user following the old doc would have
built and started cleanly, then failed on the first OSS listing.
2. The Spark/Flink line above it was generalized rather than
blanket-replaced, as you described — it now states both the 3.4.3 and 3.1.4
pairings, which is the right call since that section follows the user's own
cluster Hadoop version rather than the uber jar.
3. `docs/{en,zh}/connectors/{sink,source}/S3File.md` — the
`fs.s3a.aws.credentials.provider` row now notes that `getInstance()` is the AWS
SDK v1 fallback and is only reached when a v1 SDK jar is separately present,
since the shaded 3.4.3 uber jar ships v2 only. That matches the Hadoop 3.4.3
`CredentialProviderListFactory` call chain I traced in my last comment (v2 path
first, `AwsV1BindingSupport.createAWSV1CredentialProvider` ->
`V1ToV2AwsCredentialProviderAdapter.create` only as a v1 fallback).
4. `docs/{en,zh}/introduction/concepts/incompatible-changes.md` — a new "OSS
deployments must replace three jars together" entry, sibling to the existing
S3A entry, with the same jar-swap instructions as the OssFile.md fix and an
explicit call-out that the mismatch builds and starts clean and only fails at
runtime. This was the gap @SEZ9 and I were both pointing at.
en/zh pairs are consistent with each other in content, not just structurally
present.
**Outstanding item: CI.** As of this check, `Build` on
`9ae57a54035136a60ae6f739870fbab21083d894` is `QUEUED`, not yet `SUCCESS` — it
only started a few minutes before I looked. Given this commit touches only
Markdown, I don't expect it to move any of the jobs that were previously green,
but I'm not going to say "Ready to merge" on a check that hasn't reported back
yet; that would be exactly the kind of claim I've been holding this PR to all
along. Once `Build` finishes green on this head, I don't have any further open
item — the technical work (verified across five prior rounds) and now this doc
fix are both solid.
Conclusion in words: content-wise, this resolves the last blocker I raised;
formally, Ready to merge once CI on this exact head
(`9ae57a54035136a60ae6f739870fbab21083d894`) reports green.
---
Posting notes for whoever submits this:
- This should be posted as a plain issue-level comment (gh api
repos/apache/seatunnel/issues/11648/comments), continuing the existing
conversational thread with loustler and SEZ9 — there is no inline PR review
comment to reply to (pulls/11648/comments returns 0 results; every prior
exchange on this PR, including Daniel's own follow-ups, has been at the
issue-comment level, not inline diff comments), so no in_reply_to id applies.
- Do not submit this as a formal GitHub PR review
(APPROVE/REQUEST_CHANGES/COMMENT) — Daniel's own established pattern on this PR
is to use plain issue comments for these targeted follow-ups and reserve formal
review states for the full-pass rounds; also CI has not finished on this head,
so a formal APPROVE would be premature.
--
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]
