Flaky CI: libpostal model data download times out in the Scala and Java build

[jiayuasu]

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 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.