build(deps): bump com.github.luben:zstd-jni from 1.5.7-11 to 1.5.7-16

[dependabot]

Bumps com.github.luben:zstd-jni from 1.5.7-11 to 1.5.7-16.

Commits

• b74bc50 Guard agains negative frame content sizes
• 4188095 Forward error from setLong
• c66cdda Narrow to the private natives; keep the public signatures int
• 2836fbb Return long from the 31 natives whose C function returns size_t
• 625d27b Small tweaks in order of operations
• 1aeae2d Future version will be 1.5.7-16
• 212ec90 v1.5.7-15
• f5a61ec Simplify (and hopefully fix an error) in loading the native lib
• 3216860 Re-arange operations instead of widening to 64bits
• 2ba10c0 Fix int overflow
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[FrankChen021]

This review was performed by Codex GPT-5.6-Sol model.\nBackward compatibility: SAFE — exact PR head 1af9fb6 compared with current master 1bbb062; zstd-jni 1.5.7-16 preserves native libzstd, Druid ZSTD API and frame behavior, Java 8 compatibility, runtime graph, native resources, stored segments, and extension/plugin behavior. The only repair is the surgical licenses.yaml metadata update; the earlier packaging failure was unrelated descriptor resolution.\nThe exact head has 28/28 successful checks with no failures or pending checks.\nJava source changed: NO.

[FrankChen021]

Backward compatibility: INCOMPATIBLE — exact PR head 1af9fb6 compared with current master 1bbb062. The prior closure of apache/druid#20110 established that zstd-jni 1.5.7-15 removes decoding for legacy pre-1.0 v0.4-v0.7 frames: 1.5.7-11 decoded 5,345,280 bytes, while 1.5.7-15 failed with Unknown frame descriptor. The upstream 1.5.7-15 to 1.5.7-16 comparison contains no restoration of the removed legacy decoder, so this exact 1.5.7-16 head retains the same user-visible Druid batch-ingestion regression.

Closing as high effort: preserving legacy frame support requires an explicit product/migration decision, a legacy-enabled build, or a version cap; it cannot be safely handled by this dependency-only bump. No tracked Java production or test source changed; the PR changes only POM/license metadata.

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

[clintropolis]

removes decoding for legacy pre-1.0 v0.4-v0.7 frames

@FrankChen021 what does this mean? Assuming this means that it can't read stuff written with zstd v0.4-0.7, the first version of zstd druid supported was 1.3.3-1 in #6224, so is this an actual problem?

[FrankChen021]

removes decoding for legacy pre-1.0 v0.4-v0.7 frames

@FrankChen021 what does this mean? Assuming this means that it can't read stuff written with zstd v0.4-0.7, the first version of zstd druid supported was 1.3.3-1 in #6224, so is this an actual problem?

You’re right that Druid itself never produced these frames. The affected formats were produced by upstream native Zstd/libzstd 0.4.x–0.7.x; Druid first added zstd support at 1.3.3-1.

However, that support was for decompressing externally supplied .zst files. Druid still documents zst as a supported batch-ingestion format, and the current path delegates these files to zstd-jni. I verified that the upstream xml_v04.zst fixture decodes to 5,345,280 bytes with zstd-jni 1.5.7-11 but fails with Unknown frame descriptor on 1.5.7-15. The 1.5.7-16 README confirms that 1.5.7-12 was the last release with legacy-format support.

So there is no compatibility issue for Druid-generated segments, but there is a conditional compatibility regression for users ingesting externally generated v0.4–v0.7 .zst files. We do not have evidence that such files exist in users' Druid deployments. If Druid’s .zst contract is intended to cover only the final standard format, this can be considered out of scope; otherwise we should retain a legacy-capable version or explicitly document the migration. Or if the 1.5.7.11 has CVEs that we must resolve.

[clintropolis]

However, that support was for decompressing externally supplied .zst files. Druid still documents zst as a supported batch-ingestion format, and the current path delegates these files to zstd-jni.

Fair, I guess it just seems unfortunate to block upgrades on stuff because we can't read hypothetical batch input files that would likely have been written with a version more than 10 years old at this point. I think i'd be in favor of just calling this out in release notes and telling people to re-encode their files prior to ingest if they run into problems, but I am interested in others opinions as well.

[FrankChen021]

However, that support was for decompressing externally supplied .zst files. Druid still documents zst as a supported batch-ingestion format, and the current path delegates these files to zstd-jni.

Fair, I guess it just seems unfortunate to block upgrades on stuff because we can't read hypothetical batch input files that would likely have been written with a version more than 10 years old at this point. I think i'd be in favor of just calling this out in release notes and telling people to re-encode their files prior to ingest if they run into problems, but I am interested in others opinions as well.

We can do that.

But for us, we can't ask users to re-encode old files only when they encounter the problem. And if such problem happens, I don't think it's easy to re-encode old files, because users take time to upgrade their data pipelines to use newer zstd encoders. And such upgrading may also bring some concerns because these files are not only used by druid only.

My opinion is that if there's no severe CVEs on 1.5.7.11 or there're no new features we must to use in newer releases, let's keep using it.