[GH-ISSUE #5058] [Bug] LLDB readback drops available evidence when a later read fails #3102

New issue

Closed

opened 2026-10-31 00:36:39 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:36:39 +00:00

Owner

Originally created by @morluto on GitHub (Oct 18, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5058

Observed behavior

A later LLDB readback failure discards complete journal records and output bytes already read successfully. Current error projection reports an empty event set or unavailable capture instead of retaining the available prefix with an incomplete-read limitation.

Executed reproduction

On main 36d156ff05f48f9f0b4c4abb8f7c899249a49ebf, a small controlled file-read callback returns a short first read containing one complete JSONL event row, then rejects with EIO. readLldbObservationJournal returns only an error and no event. The analogous stdout-prefix case loses its already read text. Exact regression selection: 2 failed, 7 passed, 1 pre-existing 8 MiB allocation case skipped. No LLDB engine, investigated process or real storage fault was involved; this is the production readback helper with a simulated FileHandle and real bytes.

Root cause

readBoundedPrefix accumulates bytes internally but throws on any later chunk failure. Its caller's descriptor owner preserves a value only after the callback completes, so those earlier bytes never cross the owning boundary. Both partialNativeObservation and completed-trace capture readback therefore lose them. This is distinct from first-read failure and strict UTF8 issue #5055.

Expected behavior and structural scope

Return the successfully read prefix together with a tagged read outcome and exact failure cause. Parse only completed journal records in that prefix; return available output as incomplete/truncated, preserve sibling successes, and retain the original primary/cancellation failure. A zero-byte failure stays unavailable rather than becoming a successful empty capture. Carry the same parsed outcome through all consumers without reinterpreting raw errors, while retaining descriptor/root cleanup ownership and retry semantics.

Searched open/closed LLDB prefix/read failure issues;#4742 concerns descriptor ownership, #5055 encoding, and #4227 broader lifecycle design. No matching partial-prefix defect found. Native storage-failure prevalence, real LLDB/platform qualification, whole-agent and fault-task performance: NOT_ENOUGH_INFO. No performance improvement claimed.

Originally created by @morluto on GitHub (Oct 18, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5058 ### Observed behavior A later LLDB readback failure discards complete journal records and output bytes already read successfully. Current error projection reports an empty event set or unavailable capture instead of retaining the available prefix with an incomplete-read limitation. ### Executed reproduction On main `36d156ff05f48f9f0b4c4abb8f7c899249a49ebf`, a small controlled file-read callback returns a short first read containing one complete JSONL event row, then rejects with EIO. `readLldbObservationJournal` returns only an error and no event. The analogous stdout-prefix case loses its already read text. Exact regression selection: 2 failed, 7 passed, 1 pre-existing 8 MiB allocation case skipped. No LLDB engine, investigated process or real storage fault was involved; this is the production readback helper with a simulated FileHandle and real bytes. ### Root cause `readBoundedPrefix` accumulates bytes internally but throws on any later chunk failure. Its caller's descriptor owner preserves a value only after the callback completes, so those earlier bytes never cross the owning boundary. Both `partialNativeObservation` and completed-trace capture readback therefore lose them. This is distinct from first-read failure and strict UTF8 issue #5055. ### Expected behavior and structural scope Return the successfully read prefix together with a tagged read outcome and exact failure cause. Parse only completed journal records in that prefix; return available output as incomplete/truncated, preserve sibling successes, and retain the original primary/cancellation failure. A zero-byte failure stays unavailable rather than becoming a successful empty capture. Carry the same parsed outcome through all consumers without reinterpreting raw errors, while retaining descriptor/root cleanup ownership and retry semantics. ### Related search and limitations Searched open/closed LLDB prefix/read failure issues;#4742 concerns descriptor ownership, #5055 encoding, and #4227 broader lifecycle design. No matching partial-prefix defect found. Native storage-failure prevalence, real LLDB/platform qualification, whole-agent and fault-task performance: NOT_ENOUGH_INFO. No performance improvement claimed.

bsakaguchi closed this issue

2026-10-31 00:36:40 +00:00

bsakaguchi commented

2026-10-31 00:36:40 +00:00

Author

Owner

@morluto commented on GitHub (Oct 18, 2026):

Fixed on main in eb2c3b589; shared exact-cause prerequisite d4e233946 fixes #5059. Root cause: later chunk rejection discarded the buffer at its producing boundary. A tagged bounded-read outcome now retains successfully read bytes and exact failure. Journal/output consumers use that one outcome, keep only complete journal rows, mark retained captures incomplete, preserve siblings and primary errors, and keep zero-byte failures unavailable. Failed descriptor/root cleanup owners remain retained through retry.

Unchanged-main regressions: helpers 2 failed / 7 passed / 1 skipped; controlled production tracer 3 failed / 20 passed. Candidate also covers a completed journal row followed by EIO, exact caller cancellation reason, failed descriptor close and cleanup retry together. Test fault setup was extracted into a named scoped fixture; duplicate prefix case removed.

Validation: final affected selection passed 162 tests in 13 files; one existing 8 MiB journal allocation test skipped. Full npm run check, independent Luna reviews and commit hooks passed. Controlled production readback/provider/MCP and error-owner workflows; no actual LLDB, ADB device, GUI or storage fault. Bounded completed LLDB trace/close warm medians (two repeats/build plus separate first processes): baseline → candidate elapsed 0.16447 → 0.16405 s, CPU 0.25947 → 0.25865 s, sampled family RSS 193.8 → 194.2 MB, reply estimate 307 → 307 cl100k tokens. No true cold-cache, whole-agent or injected-failure cost measurement; no performance claim. Exact replies and probe records retained locally.

No directly related cleanup remains identified by these source/consumer reviews. Broader LLDB protocol and real-provider qualification remain incomplete.

@morluto commented on GitHub (Oct 18, 2026): Fixed on main in eb2c3b589; shared exact-cause prerequisite d4e233946 fixes #5059. Root cause: later chunk rejection discarded the buffer at its producing boundary. A tagged bounded-read outcome now retains successfully read bytes and exact failure. Journal/output consumers use that one outcome, keep only complete journal rows, mark retained captures incomplete, preserve siblings and primary errors, and keep zero-byte failures unavailable. Failed descriptor/root cleanup owners remain retained through retry. Unchanged-main regressions: helpers 2 failed / 7 passed / 1 skipped; controlled production tracer 3 failed / 20 passed. Candidate also covers a completed journal row followed by EIO, exact caller cancellation reason, failed descriptor close and cleanup retry together. Test fault setup was extracted into a named scoped fixture; duplicate prefix case removed. Validation: final affected selection passed 162 tests in 13 files; one existing 8 MiB journal allocation test skipped. Full `npm run check`, independent Luna reviews and commit hooks passed. Controlled production readback/provider/MCP and error-owner workflows; no actual LLDB, ADB device, GUI or storage fault. Bounded completed LLDB trace/close warm medians (two repeats/build plus separate first processes): baseline → candidate elapsed 0.16447 → 0.16405 s, CPU 0.25947 → 0.25865 s, sampled family RSS 193.8 → 194.2 MB, reply estimate 307 → 307 cl100k tokens. No true cold-cache, whole-agent or injected-failure cost measurement; no performance claim. Exact replies and probe records retained locally. No directly related cleanup remains identified by these source/consumer reviews. Broader LLDB protocol and real-provider qualification remain incomplete.

bsakaguchi referenced this issue

2026-10-31 01:08:01 +00:00

[PR #3102] [CLOSED] fix(setup): preserve Hermes YAML string values #5616

bsakaguchi referenced this issue

2026-10-31 01:09:46 +00:00

[PR #3568] [MERGED] fix(setup): retain Hermes YAML scalar source during updates #5832