Module content 

The two shapes a message’s content takes, read in one place.

An OpenAI message’s content is a string, or an array of parts in which the text parts carry a text field beside parts that are not text (image_url, …). VS Code’s LLM gateway sends the array form on every message. Each stage that reads or rewrites message text has to handle both, and until now each walked them inline where it needed them: canonicalisation rewrote each shape’s text in place, and truncation measured the string and skipped the array. The walk lives here so a stage that handles one shape handles the other.

Everything here works on a raw serde_json::Value, never on a typed message, because the callers forward the body they were given: a round trip through a typed message re-serialises it, and the byte stability of the forwarded prompt is what canonicalisation exists to protect.

Functions

append_text

Append text to content as a trailing piece of text, in either shape, and say whether it could be.

for_each_text_mut

Apply f to every piece of text in content, in either shape, and say how many pieces it visited.

text_len

The number of characters of text content carries, in either shape.

text_parts

The number of pieces of text content carries: 1 for a string, one per text part for an array, 0 for anything else.