jiayuasu opened a new issue, #3186: URL: https://github.com/apache/sedona/issues/3186
## Problem The `Scala and Java build` workflow intermittently fails because `AddressProcessingFunctionsTest` downloads ~1.3 GB of libpostal model data from a remote object store on every job, with no retry. Example: [run 30229831581](https://github.com/apache/sedona/actions/runs/30229831581) on `master`, job `build (3.4.0, 2.12.15, 11)`: ``` AddressProcessingFunctionsTest: ExpandAddress - should return expected normalized forms *** FAILED *** java.lang.RuntimeException: Failed to download or extract language_classifier.tar.gz at com.mapzen.jpostal.DataDownloadUtils.populateDataDir(DataDownloadUtils.java:63) at com.mapzen.jpostal.LibPostal.getInstance(LibPostal.java:57) at org.apache.spark.sql.sedona_sql.expressions.LibPostalUtils$.getExpanderFromConf(LibPostalUtils.scala:45) ... Cause: java.net.SocketTimeoutException: connect timed out ``` Four tests in that suite failed the same way, failing the whole build. ## Root cause `SedonaConf` defaults `spark.sedona.libpostal.useSenzing` to `true`, so jpostal 1.2.2 fetches its model data from `https://public-read-libpostal-data.s3.amazonaws.com/v1.1.0/`: | file | size | |---|---| | `libpostal_data.tar.gz` | 10 MB | | `parser.tar.gz` | 1266 MB | | `language_classifier.tar.gz` | 50 MB | Three things compound: 1. **No caching.** The data is re-downloaded on every job. All six matrix combinations run this suite, so a single CI run pulls roughly 8 GB. 2. **No retry.** `DataDownloadUtils.downloadFile` uses a 15 s connect timeout and does not retry, so one transient stall fails the build. 3. **The suite deletes the data directory before it runs.** `AddressProcessingFunctionsTest.beforeEach` calls `clearLibpostalDataDir()`, which recursively deletes `spark.sedona.libpostal.dataDir` (default `/tmp/libpostal`). This defeats any caching that might otherwise be added, and no test asserts on it — it only forces the download path to be exercised. ## Proposed fix 1. Cache `/tmp/libpostal` with `actions/cache` in `java.yml`. jpostal already short-circuits the download when the directory is populated: `LibPostal.getInstance` only calls `populateDataDir` when `downloadDataIfNeeded && !isDataDirPopulated(dataDir)`, and `isDataDirPopulated` just checks for `transliteration`, `numex`, `address_parser`, `address_expansions`, and `language_classifier`. 2. Pre-fetch the archives in a workflow step using `curl --retry`, so a cold cache degrades to slow rather than failed instead of relying on the no-retry download inside the test JVM. 3. Remove `clearLibpostalDataDir`/`beforeEach` from `AddressProcessingFunctionsTest` so the restored cache survives. 4. Run the suite in one matrix combination rather than all six, and only cache/pre-fetch the data in that job. Together these take libpostal network traffic from ~8 GB per CI run to zero on a warm cache. -- 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]
