T-19629 Keep sending the batch when a log argument can't be serialized

[PetrHeinz]

Fixes #26.

buildPostData() puts the raw SLF4J argument array into the payload and batchToJson() serializes the whole batch with a plain ObjectMapper, which has no cycle detection. One log line carrying a cyclic object graph — a JDBC Connection, which HikariCP logs on every pooled connection creation — makes serialization of the entire batch throw, and flushLogs() then sets retries = maxRetries and drops all of it.

The fix is a BestEffortSerialization Jackson module registered on the appender's mapper, so there is exactly one serialization pass and one way of representing data:

• A BeanSerializerModifier wraps the bean, map, collection and array serializers with a cycle guard that keeps an identity set of the objects currently being serialized — the same approach as logtail-python's frame.py. A reference looping back into the graph is replaced with "<omitted circular reference>" and everything around it stays structured JSON: a cyclic Parent argument arrives as {"Child":{"Parent":"<omitted circular reference>"}}. Only true ancestors count, so the same object referenced twice in a DAG still serializes fully both times.
• SLF4J arguments — the only place arbitrary objects enter the payload — are additionally guarded: each argument serializes once into a TokenBuffer that is then replayed into the output stream. If it fails for a reason other than a cycle (typically a getter that throws), the buffer is discarded and the whole argument is sent as "<omitted unserializable com.example.Foo>". This second layer also catches cycles threaded exclusively through serializers the modifier hooks cannot wrap (e.g. a self-referencing ObjectNode), which degrade to whole-argument omission instead of batch loss.

toString() is never called on logged objects, nothing is serialized twice, and happy-path output is byte-identical to before — verified down to @JsonUnwrapped flattening, @JsonInclude(NON_EMPTY) suppression and polymorphic default typing, each of which the guard wrappers must explicitly delegate to preserve. The one trade-off: a bean with one good getter and one throwing getter is omitted as a whole argument — there is no clean way to back out mid-object in a streaming write, and an explicit marker naming the class beats a half-object. Only exact final JDK scalar types skip the argument guard; an instanceof Number shortcut would let a subclass with a throwing toString take the whole batch down again.

Measured overhead of the always-on guard: ~0.2 ms per 1000-line batch (1.65x the bare serialization, ~200 ns per log line) on a realistic argument mix. A lazily-armed variant reaching 1.0x was prototyped and rejected: it only wins microseconds while reintroducing StackOverflowError as control flow on every batch that contains a cycle.

The first commit is the failing reproduction on its own, so the diff shows the bug reproducing before it shows it fixed. The second commit is an earlier sanitize-and-retry attempt kept in history; the third replaces it with the module. The remaining commits are a red-team pass on the module itself, each gap committed as a failing test before its fix.

Worth noting for anyone reproducing this: on the jackson-databind 2.13.5 this repo pins, the cycle surfaces as Infinite recursion (StackOverflowError), while on the reporter's 2.21.4 the same cycle trips the StreamWriteConstraints nesting-depth guard instead (Document nesting depth (1001) exceeds the maximum allowed, a guard that only exists from Jackson 2.15). With the cycle guard neither is ever thrown — the cycle is cut before the serializer can recurse.

The 9 integration tests that need BETTER_STACK_SOURCE_TOKEN fail identically on main when run without the secret — unrelated to this change.

🤖 Generated with Claude Code

[adikus]

Thank you!