Skip to content

fix(interaction): handle MoreChunkedMessages in Client.Subscribe - #103

Merged
p0fi merged 1 commit into
feat/96-list-chunk-reassemblyfrom
fix/99-subscribe-chunking
Sep 16, 2026
Merged

p0fi merged 1 commit into
feat/96-list-chunk-reassemblyfrom
fix/99-subscribe-chunking

Conversation

@p0fi

@p0fi p0fi commented Sep 16, 2026

Copy link
Copy Markdown
Owner

Summary

  • Client.Subscribe previously read exactly one ReportData message for the priming report and forwarded each ongoing ReportData message straight to Reports as soon as it arrived, without looping on MoreChunkedMessages the way Client.Read already does.
  • Both the priming-report wait and the ongoing-report goroutine now accumulate ReportData messages — acknowledging each chunk with StatusResponse(Success) as before — until MoreChunkedMessages is false/absent, then treat the accumulated AttributeReports as one complete batch.
  • Subscription.Reports's "one send = one batch" contract is now actually true instead of coincidentally true.
  • No change to Client.Read, Subscription's public struct shape, or cli/subscribe.go's buildSubscribeRecord.

Closes #99. This is a prerequisite for #96's Subscribe-side list-chunking reassembly (deferred, out of scope here), so this PR stacks on top of it (feat/96-list-chunk-reassembly → feat/98-tlv-optional → main).

Test plan

  • New unit tests using the existing fake-transport pattern: TestClient_Subscribe_ChunkedPrimingReport, TestClient_Subscribe_ChunkedOngoingReport, TestClient_Subscribe_ChunkedOngoingReport_EmptyAfterSplit
  • All existing Client.Subscribe/Client.Read tests still pass unmodified
  • mise run lint clean
  • mise run test (full suite, race-enabled) green
  • Reviewed via /code-review (Standards + Spec axes) — no hard violations found

🤖 Generated with Claude Code

Client.Subscribe read exactly one ReportData message for the priming
report and forwarded each ongoing ReportData message's fragments to
Reports as soon as they arrived, never looping on MoreChunkedMessages
the way Client.Read already does. A priming or ongoing report that
spans more than one ReportData message therefore delivered an
incomplete batch instead of one complete report per cycle.

Give both the priming-report wait and the ongoing-report goroutine the
same accumulate-until-MoreChunkedMessages-false loop, acknowledging
each chunk with StatusResponse(Success) as before, so Subscription's
"one send = one batch" contract is actually true instead of
coincidentally true.

Closes #99

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@p0fi
p0fi force-pushed the fix/99-subscribe-chunking branch from 9a6d8e7 to c5aef1e Compare September 16, 2026 21:02
@p0fi
p0fi added this pull request to stack #102 September 16, 2026 21:02
@p0fi
p0fi merged commit 26fe579 into main Sep 16, 2026
4 checks passed
@p0fi
p0fi deleted the fix/99-subscribe-chunking branch September 16, 2026 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Client.Subscribe never handles MoreChunkedMessages (priming and ongoing reports)

1 participant