Commit 0aa010a
fix(client): stream bytes as they arrive instead of filling an 8KB buffer
The streaming read loop used `readbytes!(io, buf)` with an 8KB buffer, which
blocks until the buffer is completely full (or EOF). On a low-traffic stream —
e.g. a mostly-idle Kubernetes watch — an event smaller than 8KB sits unflushed
until enough *more* bytes arrive or the connection closes, stalling the
consumer: a watch silently misses state transitions for minutes, until the
apiserver drops the connection (surfacing as "Unexpected end of input").
Replace it with `readavailable(io)`, which returns whatever is currently
buffered immediately and works on both HTTP.jl 1.x and 2.x streams. This
restores the prompt delivery of the pre-0.2.3 `read(io, 8192)` loop (swapped out
for HTTP 2.0 compatibility) without reintroducing the `read(io, n)` call that
2.0 streams don't support.
Bumps to 0.2.6.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>1 parent 39c46f6 commit 0aa010a
2 files changed
Lines changed: 15 additions & 7 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
4 | 4 | | |
5 | 5 | | |
6 | 6 | | |
7 | | - | |
| 7 | + | |
8 | 8 | | |
9 | 9 | | |
10 | 10 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
317 | 317 | | |
318 | 318 | | |
319 | 319 | | |
320 | | - | |
321 | | - | |
322 | | - | |
| 320 | + | |
| 321 | + | |
| 322 | + | |
| 323 | + | |
| 324 | + | |
| 325 | + | |
| 326 | + | |
| 327 | + | |
| 328 | + | |
| 329 | + | |
| 330 | + | |
323 | 331 | | |
324 | | - | |
325 | | - | |
326 | | - | |
| 332 | + | |
| 333 | + | |
| 334 | + | |
327 | 335 | | |
328 | 336 | | |
329 | 337 | | |
| |||
0 commit comments