Splitting a string and looping over the pieces in a server endpoint runs many more times than there are pieces and crashes — because the server returns the result in the wrong shape.
Canonical message
clean-server's `string.split` / `string_split` host bridge returns a JSON-encoded length-prefixed string (e.g. `["a","b","c","d"]`) instead of a Clean Language list-layout pointer. The compiler emits `iterate part in parts` code that reads list size from offset 0 and string-pointer elements at offset 16 + i*4. When the host returns an LP-JSON-string, offset 0 holds the JSON byte length (17 for the 4-element case), so the loop runs 17 times reading garbage past the JSON bytes — explains the dashboard report "RUNTIME_ITERATE_SPLIT_DERIVED_LIST_WRONG_LENGTH" (fingerprint 2e54b6dd700e) that prints 17 instead of 4 in production endpoints.
server
server
bridge
1
1
56.0
2026-06-19 19:30:08
2026-06-19 19:30:08
Latest Report Context
bug
unknown
foundation/spec/stdlib-reference.md line 172 says `.split(delimiter)` returns `list`. The list ABI is documented in clean-language-compiler/src/stdlib/list_ops.rs::generate_list_allocate (the in-WASM allocator that all literal lists use). Host bri
clean-server's `string.split` / `string_split` host bridge returns a JSON-encoded length-prefixed string (e.g. `["a","b","c","d"]`) instead of a Clean Language list-layout pointer. The compiler emits `iterate part in parts` code that reads list size from offset 0 and string-pointer elements at offset 16 + i*4. When the host returns an LP-JSON-string, offset 0 holds the JSON byte length (17 for the 4-element case), so the loop runs 17 times reading garbage past the JSON bytes — explains the dashboard report "RUNTIME_ITERATE_SPLIT_DERIVED_LIST_WRONG_LENGTH" (fingerprint 2e54b6dd700e) that prints 17 instead of 4 in production endpoints.
Fix Information
●●●●● resolved
1.9.55
dev-team
2026-06-19 21:13:38
79293bb
string.split now returns a proper Clean list pointer (16-byte header + N*4-byte element pointers) instead of a JSON-encoded length-prefixed string, so compiler-emitted iterate code reads the correct length at offset 0 and valid element pointers at offset 16+i*4