This is a compatibility confirmation question, not a bug — using the bug template because it is the only one available. No decoding failure has been observed.
Prior art in this repository:
A related question was recently filed as #4705 (v1.4.1 ↔ v1.5.7 in a RocksDB context). Our scenario is similar in shape but narrower in version span and specific to the raw-content prefix dictionary API, so filing separately for clarity.
Given those guarantees, we would like a targeted confirmation for our exact API shape before rolling a version bump into a large production deployment.
Scenario
We use zstd for block-level compression in a distributed service, statically linked into each node. We are upgrading from libzstd 1.5.5 to 1.5.7 as a rolling deployment. During the
rolling window (and as a rollback safety net) nodes on either version must be able to decode data produced by the other.
Encoder-side call shape (both versions)
- Single-shot buffer-to-buffer only — no streaming APIs.
- ZSTD_compress_usingDict(cctx, dst, dstCap, src, srcSize, dict, dictSize, level=6)
- ZSTD_decompress_usingDict(dctx, dst, dstCap, src, srcSize, dict, dictSize)
- dict is a raw-content prefix (not a serialized zstd dictionary with the ZSTD_MAGIC_DICTIONARY header); no ZDICT_* calls; no ZSTD_CDict / ZSTD_DDict objects.
- No ZSTD_CCtx_setParameter calls anywhere — every advanced parameter is at library default. Specifically:
- ZSTD_c_format = ZSTD_f_zstd1 (default; standard magic)
- ZSTD_c_checksumFlag = default (off)
- ZSTD_c_contentSizeFlag = default (on; srcSize is passed)
- ZSTD_c_dictIDFlag = default (raw-content prefix ⇒ no dictID embedded)
- ZSTD_c_windowLog, strategy, ZSTD_c_enableLongDistanceMatching — all default for level 6.
- Compression level: fixed at 6.
- Contexts are per-call (ZSTD_createCCtx / ZSTD_freeCCtx), not cached.
Question
Under the above encoder-side configuration, can we rely on:
- A v1.5.5 decoder correctly decompressing every frame produced by a v1.5.7 encoder, and
- A v1.5.7 decoder correctly decompressing every frame produced by a v1.5.5 encoder,
for both dictionary-compressed and non-dictionary calls, provided the same raw-content prefix bytes are supplied on both sides?
Reading #3110, #3711, and #3802, our understanding is "yes" — 1.5.6 and 1.5.7 shipped compressor fixes and decoder-tolerance improvements but no wire-format changes. We would appreciate
a one-line confirmation for the record so we can attach it to our internal rollout decision document.
Thank you.
This is a compatibility confirmation question, not a bug — using the bug template because it is the only one available. No decoding failure has been observed.
Prior art in this repository:
A related question was recently filed as #4705 (v1.4.1 ↔ v1.5.7 in a RocksDB context). Our scenario is similar in shape but narrower in version span and specific to the raw-content prefix dictionary API, so filing separately for clarity.
Given those guarantees, we would like a targeted confirmation for our exact API shape before rolling a version bump into a large production deployment.
Scenario
We use zstd for block-level compression in a distributed service, statically linked into each node. We are upgrading from libzstd 1.5.5 to 1.5.7 as a rolling deployment. During the
rolling window (and as a rollback safety net) nodes on either version must be able to decode data produced by the other.
Encoder-side call shape (both versions)
Question
Under the above encoder-side configuration, can we rely on:
for both dictionary-compressed and non-dictionary calls, provided the same raw-content prefix bytes are supplied on both sides?
Reading #3110, #3711, and #3802, our understanding is "yes" — 1.5.6 and 1.5.7 shipped compressor fixes and decoder-tolerance improvements but no wire-format changes. We would appreciate
a one-line confirmation for the record so we can attach it to our internal rollout decision document.
Thank you.