Found by Raincloud triage round 5 (#205) on bi-yalelanguages and bi-euro2016 after #225 merged — a textbook onion: fixing the RunEnd null-loss exposed the next layer.
A vortex.datetimeparts timestamp column whose days child is vortex.runend(iN?) with nullable run-values now (post-#225) correctly yields null for null runs. But DateTimePartsArrays.readLong then throws instead of producing a null timestamp:
VortexException: DateTimeParts: null cell at index 0
at DateTimePartsArrays.readLong(DateTimePartsArrays.java:32)
at LazyDateTimePartsLongArray.getLong(LazyDateTimePartsLongArray.java:45)
Before #225 the RunEnd days silently returned 0 (non-null), so DateTimeParts never saw a null; now it does and has no null handling. Semantics: the reconstructed timestamp is null iff any component (days/seconds/subseconds) is null — the extension should surface that as row validity (wrap in MaskedArray / honor a component mask), not throw.
Repro: hydrate either slug, vortex-cli export <slug>.vortex -. bi-yalelanguages fails at index 0; bi-euro2016 at index 21348 (and separately carries the ALPRD null-loss #234, currently masked behind this crash).
Found by Raincloud triage round 5 (#205) on
bi-yalelanguagesandbi-euro2016after #225 merged — a textbook onion: fixing the RunEnd null-loss exposed the next layer.A
vortex.datetimepartstimestamp column whosedayschild isvortex.runend(iN?)with nullable run-values now (post-#225) correctly yields null for null runs. ButDateTimePartsArrays.readLongthen throws instead of producing a null timestamp:Before #225 the RunEnd
dayssilently returned 0 (non-null), so DateTimeParts never saw a null; now it does and has no null handling. Semantics: the reconstructed timestamp is null iff any component (days/seconds/subseconds) is null — the extension should surface that as row validity (wrap in MaskedArray / honor a component mask), not throw.Repro: hydrate either slug,
vortex-cli export <slug>.vortex -.bi-yalelanguagesfails at index 0;bi-euro2016at index 21348 (and separately carries the ALPRD null-loss #234, currently masked behind this crash).