GeezerVison

Follow-up to e95ca8c / #70.

Problem

The new Server.readline() loop treats any buffered piece that does not end in '\n' as an incomplete line. It pops that piece and calls _read_output(init=pending), which replaces __line_buffer. Every line still buffered behind the piece is lost.

The buffer is built with str.splitlines(keepends=True), which also breaks lines on CR, FF, \x1c–\x1e, \x85 and the Unicode line/paragraph separators. SQL text in trace output can contain any of these. A bare CR inside a statement is enough to drop the rest of the chunk.

Only the last buffered piece can be an incomplete line, because it is the tail of the last query. Any earlier piece is complete; it just ends on a non-LF boundary.

Fix

if self.__line_buffer and (len(self.__line_buffer) > 1
                           or self.__line_buffer[0].endswith('\n') or self._eof):
    return self.__line_buffer.pop(0)

Evidence (live, Firebird on localhost, Windows)

Two trace sessions observed the same workload. One was read through query_timeout = 1 plus for line in srv. The other used a raw isc_info_svc_to_eof loop as reference.

2.0.3 (blocking iteration) also captures 21 of 21 in the last scenario, so this is a regression in the new loop.

Tests

• New test_text_output_non_lf_line_boundary_keeps_following_lines, in the same style as the other text_output tests. It fails on e95ca8c and passes with the fix.
• All existing text_output tests pass.
• tests/test_server.py against a live server: 45 passed. test_local_backup fails with a PermissionError with or without this change, because of local file permissions on my machine.

The rest of the timed-output design works as discussed in #71: an idle trace yields TIMEOUT without ending iteration, partial lines survive a timeout, and throughput under load matches the raw TO_EOF reader.