docs: Dekaf consumer behaviors + Spark Structured Streaming guidance#3094
Open
jwhartley wants to merge 1 commit into
Open
docs: Dekaf consumer behaviors + Spark Structured Streaming guidance#3094jwhartley wants to merge 1 commit into
jwhartley wants to merge 1 commit into
Conversation
Add a 'Consumer behaviors to know' section to using-dekaf.md (offsets are journal byte positions; the advertised latest offset can transiently move backward on a broker hand-off and is not data loss; Avro logicalType decoding; parallelism via journal splits) and a 'Reading from Apache Spark Structured Streaming' section (avoid maxOffsetsPerTrigger, handle failOnDataLoss, set the Avro datetime rebase mode explicitly).
|
🚀 Preview deployed to https://docs.estuary.dev/pr-preview/pr-3094/ 📄 Changed pages: |
aeluce
approved these changes
Jul 10, 2026
aeluce
left a comment
aeluce
left a comment
Collaborator
There was a problem hiding this comment.
Super helpful to collect these from real support cases, thanks!
Had some minor suggestions, though fine from my end to continue without them.
| silently drop records that fail to decode — switch to a strict or fail-fast mode to surface | ||
| the error rather than discarding the record. | ||
|
|
||
| ## Consumer behaviors to know |
Collaborator
There was a problem hiding this comment.
Suggested change
| ## Consumer behaviors to know | |
| ## Consumer behaviors |
Minor nit that anything in docs is something we think someone should know so we could leave that part off. Would affect anchor links further down the doc.
| collection into more journals. A split only distributes data written after it; to spread an | ||
| existing backlog across the new journals you also need to re-backfill from the source. A | ||
| split is a collection-level change, so every materialization on the collection sees the new | ||
| journals (non-breaking). Contact Estuary support before splitting a production collection. |
Collaborator
There was a problem hiding this comment.
Will journal auto-splitting for v2 affect this advice?
|
|
||
| ### Set the Avro datetime rebase mode explicitly | ||
|
|
||
| Spark's `PERMISSIVE` Avro mode silently nulls values it cannot parse, including dates before |
Collaborator
There was a problem hiding this comment.
This section doesn't scan super easily and may be difficult to parse. What do you think of reordering it like this?
Spark's `PERMISSIVE` Avro mode silently nulls values it cannot parse, so affected records
look empty or missing. Use `FAILFAST` while debugging to surface the real error. You can
then choose how you'd like to handle these values.
For example, dates before the Gregorian cutover, like `1582-10-15`, cannot be parsed with
permissive null-ing. With `FAILFAST`, the underlying
`INCONSISTENT_BEHAVIOR_CROSS_VERSION.READ_ANCIENT_DATETIME` error is exposed,
and you can set `spark.sql.avro.datetimeRebaseModeInRead` to handle old datetime values:
* Use `CORRECTED` to read values as-is
* Use `LEGACY` to rebase across the calendar difference
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Extends
using-dekaf.mdwith consumer guidance that has come up repeatedly in support, in two layers:flowctl collections read); AvrologicalTypedecoding (e.g. uuid -> UUID object); parallelism via journal splits.maxOffsetsPerTrigger(byte-budget cap drops partial records), handlefailOnDataLoss(it aborts on the transient backward-offset case), and setspark.sql.avro.datetimeRebaseModeInReadexplicitly (PERMISSIVE silently nulls pre-Gregorian dates, SPARK-31404). Plus an example reader config.Why
These are recurring, non-obvious Dekaf consumer issues. The byte-offset model, the transient latest-offset regression, and the Avro decoding traps each surfaced as "missing data" reports that turned out to be consumer-side or transient. The transient-latest behavior is tracked in #3092.
Part 1 lives with the general consumer guidance so non-Spark consumers (Flink, librdkafka, kcat) benefit too; Part 2 is the Spark-specific config that builds on it.
Notes