Chapter 16 - Worked Answers

1. Information lost in plain text

LogLine carries stdout/stderr identity and a read-time timestamp. The final handler prints the text line, so those structured fields disappear. Concurrent scanners can interleave outputs, and visible ordering cannot reconstruct which source stream produced identical text. A timestamp assigned at scanning is also not necessarily the application event’s original time. Preserving that information would require a separately documented structured public response format and compatible clients.

2. Tail versus follow

Tail selects how much existing history the Engine should return; follow asks to continue as new output arrives. They are independent. In the worker handler, a malformed tail string falls back to all. A negative string that parses as an integer follows a different path and is passed onward; do not describe all invalid-looking inputs as identical. This answer traces current parsing, not a recommendation to request unbounded logs. Use a small explicit tail and a bounded client deadline in the live lab.

3. Cooperative cancellation scope

The passing fake log fixture waits on context cancellation and then closes its channels. That establishes the handler/fake contract. Real Engine streaming includes a response reader, stdcopy, two pipes and scanners that can block before reaching the context-aware send. A select around the output send alone cannot prove every blocked read wakes on disconnect. A separate real local experiment must inspect reader/pipe closure and bounded goroutine completion under its own failure schedule.

4. A bounded slow-consumer extension

Define a maximum line/byte queue, a client write deadline and an explicit overflow policy such as closing the stream with a recorded diagnostic. Avoid a silent unlimited buffer. Inject a consumer that stops reading, then remove the task or cancel its request; assert bounded memory/queue size, closed runtime readers/channels and goroutine completion within the test deadline. Also assert that midstream errors do not attempt to replace already-sent plain-text headers with a JSON error status. This is an unimplemented design answer, not a claim that the current adapter has that complete policy.

These answers distinguish source reasoning from the scoped execution records linked in chapter 16. Proposed changes require separate implementation and validation.