Release v1.1.0 · aehrc/fhir-bulk-java

Security

Fixed a path traversal vulnerability in bulk export downloads (#11): a malicious or malformed export manifest could previously cause files to be written outside the intended output directory (e.g. via absolute paths, .. segments, or a pre-placed symlink at the destination). The manifest is now validated where it enters the system — each resource type must match a safe character class — so a resolved path can never escape the output directory. A symlink at the download destination is now refused rather than followed; a plain file already there is overwritten (needed for retry, see below).
Bumped dependencies flagged by Dependabot (#18): logback (1.2.11 → 1.5.34), commons-io (2.13.0 → 2.14.0), org.json (20230618 → 20231013), and wiremock-jre8-standalone (test-only, 2.35.0 → 2.35.1).

Retry downloads that are cut short mid-transfer (#16): previously, one truncated file download would abandon an entire export. Each file now gets multiple attempts (configurable), rewritten from the start each time, and the retry delay is bounded and randomised (jittered) rather than exponential, so concurrent downloads that fail together don't all back off in lockstep. New public DownloadConfig, settable on the client builder, controls maxRetries and the delay bound; a default is used if not supplied.
Allow a caller to supply their own Hadoop FileSystem to HdfsFileStoreFactory via a new forFileSystem API (#13), for callers that need to control filesystem identity/configuration directly (e.g. under user impersonation).
Output file extension is now inferred from the outputFormat MIME type (#10) — application/fhir+ndjson/application/x-ndjson → .ndjson, application/vnd.apache.parquet → .parquet, unknown formats default to .ndjson. outputExtension is now optional and, when set, overrides the inferred value.

Stopped closing a shared Hadoop filesystem (#13): HdfsFileStoreFactory was closing a FileSystem instance obtained from Hadoop's JVM-wide cache, which is shared with the host application. A successful export would leave a closed, unusable instance in the cache, breaking all subsequent access to that scheme until the process was restarted. Closing the store is now a no-op — the filesystem is borrowed, not owned.

Full changelog: v1.0.4...v1.1.0