Repository navigation
test(spark): characterize HadoopUtils S3 and Azure credential forwarding - #8850
Merged
robert3005 merged 1 commit intoAug 3, 2026
Merged
Conversation
This was referenced Jul 20, 2026
Merging this PR will regress 2 benchmarks
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
jackylee-ch
force-pushed
the
spark-hadoop-utils-tests
branch
from
July 21, 2026 10:32
f8cb4b4 to
e4fa40e
Compare
Signed-off-by: jackylee <qcsd2011@gmail.com>
jackylee-ch
force-pushed
the
spark-hadoop-utils-tests
branch
from
August 3, 2026 10:41
e4fa40e to
b48023b
Compare
robert3005
pushed a commit
that referenced
this pull request
Aug 3, 2026
…8859) ## Rationale for this change `VortexBatchExec` (`java/vortex-spark/src/main/java/dev/vortex/spark/read/VortexBatchExec.java`) turns the scan's resolved paths into Spark `InputPartition`s, and it currently has no direct test coverage. Its planning contract is easy to break silently: each `.vortex` file must become exactly one `VortexFilePartition`, each partition must carry the Hive-style partition values parsed from *its own* path (not a neighbour's), and the read schema and format options must survive into every partition — these are what the executor-side reader relies on to materialize partition columns correctly. This continues the characterization-test series from #8770, #8782, #8783, #8850, and #8857. ## What changes are included in this PR? A new `VortexBatchExecTest` with 5 tests covering `planInputPartitions` for explicit `.vortex` paths (which never touch native directory listing, keeping this a pure unit test): - one `VortexFilePartition` per file, each holding exactly one path; - partitions preserve the input path order; - the requested read schema is carried into every partition; - Hive-style partition values are parsed from each file's own path (`year=2024/month=01` vs `year=2025/month=02` vs an unpartitioned path yielding an empty map); - format options are propagated to every partition. This is a **test-only** change; no production code is modified. All 5 tests pass locally on both matrix legs (`:vortex-spark_2.12:test` and `:vortex-spark_2.13:test` with `--tests 'dev.vortex.spark.read.VortexBatchExecTest'`). ## What APIs are changed? Are there any user-facing changes? None. No production code or public API is touched. Signed-off-by: jackylee <qcsd2011@gmail.com>
robert3005
enabled auto-merge (squash)
August 3, 2026 11:00
robert3005
approved these changes
Aug 3, 2026
robert3005
pushed a commit
that referenced
this pull request
Aug 6, 2026
…ing (#8857) ## Rationale for this change `VortexScanBuilder` (`java/vortex-spark/src/main/java/dev/vortex/spark/read/VortexScanBuilder.java`) decides which Spark V2 predicates are pushed into the Vortex scan and which are returned to Spark for post-scan evaluation, and it currently has no direct test coverage. The split logic encodes correctness-critical rules: predicates referencing partition columns must *not* be pushed (partition values live in directory paths, not inside the Vortex files), untranslatable operators must be returned to Spark, and `pushedPredicates()` must not expose internal state. A regression in any of these silently drops filters or scans the wrong data. This continues the characterization-test series from #8770, #8782, #8783, and #8850. ## What changes are included in this PR? A new `VortexScanBuilderTest` with 9 tests covering: - **`pushPredicates` on data columns**: a supported predicate on a data column is pushed and removed from the post-scan set; predicates referencing columns absent from the read schema, or using operators `SparkPredicateToVortexExpression` cannot translate (e.g. a raw `LIKE`), are returned to Spark and never recorded as pushed. - **`pushPredicates` on partition columns**: a predicate on an identity-partitioned column is left to Spark; mixed batches split correctly (data-column predicate pushed, partition-column predicate post-scan); an `And` spanning a data column and a partition column is kept whole on the Spark side. - **`pushedPredicates`**: empty before any push, and returns a defensive copy so callers cannot mutate the builder's internal state. - **`build`**: fails fast with `IllegalStateException` when no paths were added. This is a **test-only** change; no production code is modified. All tests pass locally on both matrix legs (`:vortex-spark_2.12:test` and `:vortex-spark_2.13:test` with `--tests 'dev.vortex.spark.read.VortexScanBuilderTest'`). ## What APIs are changed? Are there any user-facing changes? None. No production code or public API is touched. Signed-off-by: jackylee <qcsd2011@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale for this change
HadoopUtils(java/vortex-spark/src/main/java/dev/vortex/spark/config/HadoopUtils.java)is the bridge that forwards S3 and Azure credentials from the Spark session's Hadoop
Configurationinto the Vortex object-store property keys, and it currently has no testcoverage. A silently broken key mapping here doesn't fail loudly — it surfaces as
authentication errors (or unintentionally anonymous access via the Azure
skip_signaturefallback) only when running against real cloud storage. This continuesthe characterization-test series from #8770 (
ArrowUtils), #8782 (SparkToArrowSchema),and #8783 (
PartitionPathUtils).What changes are included in this PR?
A new
HadoopUtilsTestcovering both public methods:s3PropertiesFromHadoopConf: mapsfs.s3a.access.key/fs.s3a.secret.key/fs.s3a.session.token/fs.s3a.endpoint.regionto the correspondingaws_*keys;qualifies a bare
fs.s3a.endpointwithhttps://while preserving endpoints thatalready carry an
http://orhttps://scheme; ignores unrelated Hadoop keys andreturns an empty map for an empty configuration.
azurePropertiesFromHadoopConf: extracts the storage account key from anyfs.azure.account.key-prefixed entry and the SAS token from anyfs.azure.sas.fixed.token.-prefixed entry; setsazure_skip_signature=truewheneverno account key is present (including the SAS-token-only case); ignores unrelated
fs.azure.*keys.This is a test-only change; no production code is modified. 10 tests, passing
locally on both matrix legs (
:vortex-spark_2.12:testand:vortex-spark_2.13:testwith
--tests 'dev.vortex.spark.config.HadoopUtilsTest').What APIs are changed? Are there any user-facing changes?
None. No production code or public API is touched.