withVersion pushes an event already at MAX_TAGS over the server's tag limit #13

withVersion (src/main/java/software/stephenson/trace/TraceClient.java, around line 671) always adds the version tag unless the event already carries one. It never checks MAX_TAGS. Every other tag the client adds on its own is capped:

• withInstall returns the map unchanged when tags.size() >= MAX_TAGS
• withServerWideTags stops adding when merged.size() >= MAX_TAGS, and its Javadoc says the merge "never makes a report the server would reject"

The comment above MAX_TAGS says the trace server's MetricDto accepts at most MAX_TAGS (32) pairs.

Reproduction (traced through the code): report("x", null, tags) with 32 distinct non-null tags, none named version:

1. withVersion copies the 32 tags and adds version, giving 33.
2. withInstall sees size() >= 32 and adds nothing.
3. withServerWideTags either returns the 33-entry map unchanged (no server-wide tags) or breaks immediately.
4. json() writes all 33 pairs, and the server is expected to answer 400. The report is dropped, and a FINE "trace server answered 400" line is logged.

A host program that sends exactly the server's limit therefore has every report rejected. The only reason is the tag the client adds itself.

Options for the maintainer (this changes what is sent on the wire, so it needs a human decision):

• skip version when the event already has MAX_TAGS tags, like withInstall does; or
• let version take precedence and drop one of the event's own tags (that would contradict "an event's own tag wins"); or
• leave it as it is and document that programs get MAX_TAGS - 1 tags of their own.

A characterization test pinning the current behaviour is being added in a Stage B test-expansion PR.

This issue was drafted during a Gardener session (https://github.com/Stephenson-Software/gardener).

drafted by Claude on behalf of Daniel Stephenson