You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A coalesced count at MAX_TAGS, or on an event with its own coalesced tag, is sent without its count tag #31
When a coalesced event's count is sent, it can go out without the coalesced tag. When that happens, the counting formula documented in the report(String, Double, Map) Javadoc and the README ("sum of value where coalesced is present, 1 where it is not") gives the wrong total for that event.
Where:src/main/java/software/stephenson/trace/TraceClient.java, withCount. flush builds each count event with withCount(window.tags, window.count), and withCount adds coalesced=<n> only when !merged.containsKey(COALESCED_TAG) && merged.size() < MAX_TAGS.
Two cases follow from that condition (both pinned by withCount_addsTheCountOnlyWhenThereIsRoomAndNoneAlready):
The event already carries MAX_TAGS (32) tags once version, install and the server-wide tags are added. The count event is sent with value=<n> (for a valueless event) but without a coalesced tag. A query following the documented formula counts it as 1 instead of n. If the event had its own value, the count is lost from the payload completely: value keeps the event's value and no tag carries n.
The event carries its own coalesced tag. The count event keeps the program's value of that tag, so a reader cannot tell a count from a single report, and the actual count n appears nowhere in the body when the event has a value.
Why it matters: both cases are rare: 32 tags is the server's limit, and coalesced is a name the client now uses for itself. But since 0.7.0, the documented formula is the only way to recover "how many times" from stored events, and in these cases it undercounts without any sign. The docs-sweep PR that files this issue documents the current behaviour in the README and Javadoc. It does not change it.
Options for the maintainer (this changes what is sent on the wire, so it needs a human decision):
when there is no room for the tag, drop one of the event's own tags or a server-wide tag to make room (this contradicts "an event's own tag wins");
skip coalescing for events that cannot carry the tag, i.e. send every repeat (this gives up the flood protection for those events);
reserve the coalesced tag name: strip or rename an event's own coalesced tag before coalescing; or
keep the current behaviour (now documented).
Related: #13, where withVersion and MAX_TAGS interact in a similar way.
Activity
Bring the docs up to date with coalescing (#32)