JingsongLi commented on PR #10190: URL: https://github.com/apache/paimon/pull/10190#issuecomment-5951479557
The endpoint normalization has a real benefit and I did not find an unintended regression in this diff. Beyond the two new tests, I verified the generated options using the actual pinned Vortex 0.70.0 SDK against a local HTTPS range-serving fixture: https/http/plain endpoint inputs each read 500 rows and nulls correctly; object key, virtual-hosted endpoint, SigV4 header and session token remain correct. The old doubled-scheme endpoint fails. This fixture does not certify live OSS service behavior. There is a separate, pre-existing blocker to the PR's stated end-to-end read workflow at this head. `dev/requirements-dev.txt` pins `vortex-data==0.70.0`, but `FormatVortexReader` calls `vortex_store.open()`. A 0.70.0 S3Store has no such method. Invoking the actual `FormatVortexReader` with the fixed OSS endpoint raises: ``` AttributeError: 'builtins.S3Store' object has no attribute 'open' ``` The supported SDK entry point is `vortex.open(path, store=...)`; I used that API in the transport verification above. This reader/API mismatch is already present on the base and is not a regression introduced by the endpoint change. However, the current production read cannot complete until it is resolved, preferably with a real SDK-backed reader test. Please account for that alongside this fix so the intended OSS Vortex read workflow is actually usable. -- 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]
