[connortsui20]

Summary

• Tracking Issue: Tracking Issue: Fix Canonical Decimal #10701

The prost getters for enumeration fields decode an unknown stored value as the first variant, so a stored DecimalType or PType outside its enum silently read as I8 or U8. A file read now returns a Serde error instead.

Changes

Each metadata struct with a stored DecimalType or PType field gets a get_<field>() accessor that rejects an unknown value, and each deserialize calls it right after decoding the metadata, before any buffer or child read. The protobuf dtype decoder converts its PType through pb::PType::try_from in the same way, which also covers the dtypes stored by Variant arrays, scalars and cast options. The flatbuffer path was already strict, and its error now includes the raw value. The wire format does not change, and every value that a current writer stores reads as before. Each rejection test goes through the real deserialize or layout build path and checks the full Serde error with a new test_harness::assert_serde_error helper. compat.py check --mode all passes against every published fixture.

The decimal width has to be strict before the read path for old decimal arrays in #10701 can rely on it. For review, read the commits one at a time: the decimal width, the protobuf dtype, then the eleven PType fields of array and layout metadata.

🤖 Generated with Claude Code

[codspeed]

Merging this PR will regress 3 benchmarks

4 warnings, 1 note

⚠️ Walltime results may be unreliable

Some benchmarks used the Walltime instrument outside CodSpeed Macro Runners, which can make the results inconsistent.

Learn more about Macro Runners

See affected benchmarks

⚠️ Unable to measure the execution of 2 benchmarks

These benchmarks measured no execution time, so their results are not comparable and count as unchanged. This usually happens when the compiler removes the code under test.

Prevent compiler optimizations

See affected benchmarks

⚠️ 22 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ Base and head ran on different runner types

Some benchmarks with significant performance changes were compared across different runner types, so the changes might not come from the code. Run base and head on the same runner type, or use CodSpeed Macro Runners for more stable results.

Learn more about Macro Runners

Open the report in CodSpeed to investigate

ℹ️ 40 benchmarks have no flamegraph

The flamegraph wasn't generated: the symbols of the profiling trace could not be resolved, because no information about the language frames was collected.

See affected benchmarks

⚡ 4 improved benchmarks
❌ 3 regressed benchmarks
✅ 2401 untouched benchmarks
⏩ 12 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	CPU Simulation	test_repeated_scan_scalar_at[int]	243.3 µs	329.2 µs	-26.07%
❌	Walltime	bitpack_blocked_compress_avx2	6.7 µs	7.6 µs	-11.17%
❌	CPU Simulation	density_sweep_dense_runs[0.001]	53.6 µs	59.6 µs	-10.03%
⚡	CPU Simulation	bench_compare_primitive[(10000, 32)]	97 µs	71.3 µs	+36.07%
⚡	CPU Simulation	missing_stats[16]	85.6 µs	71.7 µs	+19.42%
⚡	Walltime	starts_with_avx2[8, VarBin]	46.9 µs	40.1 µs	+16.97%
⚡	Walltime	starts_with_avx512[64, VarBin]	60.4 µs	53.3 µs	+13.17%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing ct/strict-enum-decoding (12ad928) with develop (3974ee0)}

Footnotes

1. 12 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩