With emitReportsToLogger=true, a full report reaches the stacktale.reports logger and a recurrence summary does not. In ReportPipeline.process:
case REPORT -> {
...
writer.append(rendered);
...
if (settings.emitReportsToLogger()) host.emitReport(rendered);
}
case SUMMARY -> {
writer.append(renderer.renderSummary(fingerprint, decision.count(), decision.lastSeenMillis()));
deduper.confirmWritten(fingerprint, decision.count());
summariesWritten.incrementAndGet();
}The SUMMARY arm never calls host.emitReport.
For anyone reading the file this is invisible — both land there. For the reader this flag exists for, the one whose reports only ever appear on stdout, it means the same error looks like it happened once. The summary is where "and then it happened another 46 times" lives, so it is arguably the line that matters most to somebody watching a shipper.
What to change
Emit the summary the same way the report is emitted. It is a small change in the SUMMARY arm, and the ordering matters for the same reason it does above: deduper.confirmWritten must stay after the append, because a failed append has to leave the count pending for close()'s drainPending(). The emission goes last, after the state is settled — a failing shipper must not undo dedup state.
Then say it in the README. The Configuration section describes emitReportsToLogger as one report per event; once summaries go too, that sentence needs to cover both.
How to check you got it right
- A test that logs the same error twice inside the dedup window with
emitReportsToLogger=true, and asserts two events on stacktale.reports rather than one. LogbackXmlConfigTest shows how to attach a listener to a named logger; DeduperTest shows how to cross a window without sleeping.
- Assert on the content of the second event, not just the count — a summary that arrives with the report's own text would pass a count-only assertion and be useless.
mvn verify green, and no golden file touched: this changes what reaches the logger, not what is written to the report file.
Say the word here and it's yours.
Found while reviewing #232. See also #233, which is about the larger question of whether this flag should work without a file at all.
With
emitReportsToLogger=true, a full report reaches thestacktale.reportslogger and a recurrence summary does not. InReportPipeline.process:The
SUMMARYarm never callshost.emitReport.For anyone reading the file this is invisible — both land there. For the reader this flag exists for, the one whose reports only ever appear on stdout, it means the same error looks like it happened once. The summary is where "and then it happened another 46 times" lives, so it is arguably the line that matters most to somebody watching a shipper.
What to change
Emit the summary the same way the report is emitted. It is a small change in the
SUMMARYarm, and the ordering matters for the same reason it does above:deduper.confirmWrittenmust stay after the append, because a failed append has to leave the count pending forclose()'sdrainPending(). The emission goes last, after the state is settled — a failing shipper must not undo dedup state.Then say it in the README. The Configuration section describes
emitReportsToLoggeras one report per event; once summaries go too, that sentence needs to cover both.How to check you got it right
emitReportsToLogger=true, and asserts two events onstacktale.reportsrather than one.LogbackXmlConfigTestshows how to attach a listener to a named logger;DeduperTestshows how to cross a window without sleeping.mvn verifygreen, and no golden file touched: this changes what reaches the logger, not what is written to the report file.Say the word here and it's yours.
Found while reviewing #232. See also #233, which is about the larger question of whether this flag should work without a file at all.