Skip to content

bugfix: LLO report gaps#231

Draft
calvwang9 wants to merge 5 commits intomasterfrom
bugfix/llo-report-gap
Draft

bugfix: LLO report gaps#231
calvwang9 wants to merge 5 commits intomasterfrom
bugfix/llo-report-gap

Conversation

@calvwang9
Copy link

@calvwang9 calvwang9 commented Mar 7, 2026

full bug report: https://docs.google.com/document/d/1lJaCveFuS7oFW4sAF5A7-H7sSOYJOkpo88X4JPZ17ys/edit?usp=sharing

This change addresses a bug in the LLO outcome plugins that results in report gaps.

The bug:
Currently a channel's validAfterNanoseconds is updated to the previous observationsTimestamp field based on the IsReportable check on the previous outcome only. This check doesnt have any knowledge about whether a report was actually generated from the previous outcome, so when reports are (silently) dropped due to missing stream values or otherwise, valid after updates regardless, leading to a continuity error/report gap.

The fix:
Add a simulation check in the outcome step to perform a soft check for whether the previous outcome would have successfully produced a report, and do not update the valid after timestamp if not. This will catch the most common fail cases related to nil stream values.

However this is not a hard guarantee on report success - outcomes are produced before reports, and there is no feedback from report generation to the next round of outcome generation. If the report was dropped for any other reasons it would not be caught by this simulation.

@calvwang9 calvwang9 marked this pull request as ready for review March 9, 2026 04:33
@calvwang9 calvwang9 requested a review from a team as a code owner March 9, 2026 04:33
@calvwang9 calvwang9 requested review from brunotm and namikmesic March 9, 2026 04:36
Copy link
Contributor

@brunotm brunotm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a really good catch @calvwang9 🚀

But we can't do the full encode on the IsEncodable as this has the potential of substantially increase/impact the cpu time and outcome generation time under the right (wrong) conditions.

We should instead verify that all elements for encoding are present and valid:

  • All stream values are present and are not nil
  • All required timestamps are present and valid
  • etc

@calvwang9 calvwang9 requested a review from brunotm March 9, 2026 12:36
@calvwang9 calvwang9 enabled auto-merge (squash) March 9, 2026 12:48
@brunotm brunotm marked this pull request as draft March 9, 2026 13:25
auto-merge was automatically disabled March 9, 2026 13:25

Pull request was converted to draft

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.

2 participants