mrproliu commented on PR #1133:
URL:
https://github.com/apache/skywalking-banyandb/pull/1133#issuecomment-4465122830
Quick clarification on the trade-off before I pick a direction:
Just restoring pre-walk and reverting Mark*++Counts doesn't fully bring
the planned semantic back — for series and element_index, the visitor sets
Counts = len(segmentFiles)
at the top of VisitSeries / VisitElementIndex, but Mark* runs inside for
targetSegments × shardIDs. When fan-out > 1 (typical hot → warm), Mark calls
exceed source files and the report ends up with e.g. series.completion_rate =
266.67%,
while element_index flips the other way to single-digit % with errors = 0.
Operators in the original SRE report flagged exactly those numbers.
So "Counts = pre-walk source" and "rate stays in [0,100]" cannot both hold
for series / element_index under the current visitor shape. To avoid the 266%
regression there are three options:
1. Document & accept: keep pre-walk semantic, treat rate > 100% as
"fan-out write count exceeded source count" and document it.
2. Bump report_version to 2.1: add planned_* fields from pre-walk
alongside existing fields; old fields stay [0,100], planned_completion_rate
gives the mid-flight progress signal.
3. Refactor the visitor: collapse per-source Mark* to one call (lose
per-target granularity for retries, but Counts = source = mark calls becomes
consistent).
Which one do you prefer?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
