sundapeng commented on PR #1014: URL: https://github.com/apache/paimon-rust/pull/1014#issuecomment-6621169153
Thanks for the review. I rechecked the current Java and Python implementations against the same effective-options and endpoint-boundary cases before asking for another Rust pass. - Java #10350 is at `39e3428fa2`. Its REST FileIO cache is keyed by the vended token plus an immutable copy of the catalog options (`84363ffb61`), and native-format consumers intentionally receive origin options while per-request target routing stays in the internal routed path (`5af45bcc21`). - Python #10351 is at `4b1bd71b98`. Forked routing state is recreated before target-lock use (`bf0c925930`); external/native paths use effective origin options (`8e65f00259`, `2bd427a35c`, `1484678568`, `66b450c72c`); and catalog overrides are reapplied after token merging, including shared-token reuse (`52fb0b9c86`). - These boundaries match Rust: `RESTTokenFileIO` applies catalog/token options per instance, endpoint-bound state is not shared across catalogs, and externally owned URI/source reads stay on the origin. I found no additional cross-client mismatch or Rust change needed. The current Rust head is `319f3668`, including the updated upstream baseline. Required CI run [41672940690](https://github.com/apache/paimon-rust/actions/runs/41672940690) is green across all 15 jobs; local formatting, dependency policy checks, and the core library tests also pass (`4,859 passed; 6 ignored`). Could you please take another look and update the review status? Live OSS accelerator/STS and production throughput remain untested. -- 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]
