Stop Sequences & Streaming

The problem, from first principles

APIs let callers pass stop sequences: generation ends when the output contains one, and the stop text itself is not returned. Doing this on the full text is easy, but a streaming server must decide, token by token, which characters it can already send to the client. If the buffer ends with "\n\nUs" and the stop sequence is "\n\nUser:", those last characters might turn out to be the start of the stop sequence, so they must be held back until the next token resolves the ambiguity. This question builds both pieces: truncating at the earliest stop, and computing how much of the buffer is safe to emit.

From theory to code

Implement truncate_at_stop and safe_emit_length.

Constraints

• truncate_at_stop(text, stops) returns (clean_text, hit). If any stop string occurs in text, cut at the earliest occurrence (the smallest index among all stops) and return (text[:index], True). Otherwise return (text, False). Empty stop strings are ignored.
• safe_emit_length(buffer, stops) returns how many leading characters of buffer can be sent now, assuming no stop sequence has fully appeared. It is len(buffer) minus the length of the longest suffix of buffer that is a proper prefix of some stop string. If no suffix of the buffer is a proper prefix of a stop string, nothing is held back and the full length is returned.
• A proper prefix is shorter than the whole stop string.

Hints