bug: Repeating section Parse silently truncates at 128 items due to fixed stackalloc buffer

[DrBarnabus]

Description

The generated Parse and TryParse methods for repeating sections use a fixed-size stack-allocated buffer:

Span<Range> tagsRanges = stackalloc Range[128];

If a key contains more than 128 items in a repeating section, MemoryExtensions.Split will silently truncate the results. This produces an incorrect parse result rather than a clear error.

Reproduction

Visible in the snapshot baseline:
SourceGeneratorSnapshotTests.RepeatingPropertyCompositeKey_SourceOutput#UnitTests.UserTagKey.g.verified.cs (lines ~184-185 for Parse, ~235 for TryParse)

Expected behaviour

The generated code should either:

• Detect when the buffer is exhausted (i.e. tagsCount == 128) and fall back to a heap allocation or return a clear error
• Or document the 128-item limit as a known constraint

Discovered via

Snapshot testing added in #48 — this is a pre-existing generator issue, not a regression.

[DrBarnabus]

Investigation

Category

Bug — Low Severity / Edge Case. Pre-existing generator issue (not a regression). Only affects keys with 128+ items in a repeating section.

Root Cause

Two locations in SourceGenerator.Emitter.cs emit a fixed stackalloc Range[128] buffer for splitting repeating sections:

1. Line 378 — "same separator" path: when the repeating property's separator is the same as the key delimiters, the buffer is used for the main key split.
2. Line 564 — "different separator" path: when the repeating property has its own separator, the buffer is used for a sub-split of just the repeating section.

Correction to Issue Description

The issue states that MemoryExtensions.Split will "silently truncate the results" — this is not quite accurate. Per the .NET documentation:

If there are more regions in source than will fit in destination, the first destination length minus 1 ranges are stored in destination, and a range for the remainder of source is stored in destination.

So with a 128-slot buffer and 200 items: slots 0–126 get individual items, and slot 127 gets the entire unsplit remainder (items 128–200 still joined with delimiters). The return value is 128.

The actual failure mode depends on the property type:

Property Type	Behavior with 129+ items	Severity
Typed (List<Guid>, List<int>, etc.)	Item 128 is "guid128#guid129#..." — TryParseExact fails, throwing a generic FormatException("Unrecognized format.")	Confusing error (not silent, but misleading)
String (List<string>)	Item 128 is "tag128#tag129#tag130" which passes the Length == 0 check and gets added as a single string containing all remaining items with delimiters	Silent data corruption

Reproduction

The issue is visible in the generated code but not currently triggered by any test. All existing functional tests use 1–3 items in repeating sections.

To reproduce the string corruption case, a test would need to:

1. Define a key type with List<string> repeating property
2. Format a key with 129+ string items via ToString()
3. Parse it back — the resulting list would have 128 items, with the last item containing all overflow items concatenated

Impact Assessment

Low practical impact for the intended DynamoDB use case:

• DynamoDB partition keys max out at 2048 bytes, sort keys at 1024 bytes
• With GUIDs (36 chars + 1 delimiter): max ~28 items in a sort key — well under 128
• With short strings (2 chars + 1 delimiter): max ~340 items — could exceed 128
• Most real-world composite keys have a handful of repeating items at most

However, the library is not strictly DynamoDB-only, and silent data corruption (for string collections) is the worst class of bug regardless of likelihood.

Fix Options

Option A: Detect exhaustion and throw a clear error (Recommended)
After the Split call, check if returnedCount == 128 (buffer capacity). If so, throw/return-false with a descriptive message like "Repeating section exceeds maximum of 127 items." This is a one-line addition per site, establishes a documented limit, and turns silent corruption into a clear error.

// Add after each Split call on the 128-buffer:
if ({countVar} == 128)
    throw new FormatException("Repeating section exceeds the maximum supported item count (127).");

Option B: Use SpanSplitEnumerator (enumerate without fixed buffer)
.NET 8+ provides ReadOnlySpan<char>.Split(separator) returning a SpanSplitEnumerator<char> — no fixed buffer needed. This removes the limit entirely but changes the code generation approach (iterator-based instead of index-based) and would need to handle StringSplitOptions manually since the enumerator doesn't support options directly. More invasive change.

Option C: Retry with heap allocation
If count == bufferSize, rent from ArrayPool<Range> with a larger size and retry. Removes the limit while keeping the same code shape, but adds complexity and a second code path.

Recommendation

Option A is the right fix. It's minimal, safe, and turns an invisible problem into an explicit error. 127 items is more than sufficient for any realistic composite key. Option B or C could be considered later if a legitimate need for 128+ items arises.

The fix touches two locations in SourceGenerator.Emitter.cs (lines 378 and 564), plus snapshot baselines would need updating.