No test coverage for KafkaSink / x5f2 serialization path

[SimonHeybrock]

Problem

grep -r KafkaSink tests/ returns nothing. There is no test anywhere that exercises KafkaSink.publish_messages, which is where service_status_to_x5f2 / job_status_to_x5f2 are actually invoked in production. Similarly, no test drives a real confluent_kafka.Message through the adapter layer.

FakeMessageSink skips serialization entirely, so every LivedataApp/OrchestratingProcessor-based integration test silently avoids the Kafka encoding path. This is how both issues fixed in #847 slipped through CI:

1. ServiceStatusPayload.started_at: int vs ServiceStatus.started_at: Timestamp mismatch — killed every backend service on its first heartbeat on main after Add Timestamp and Duration types for nanosecond values #829.
2. X5f2ToStatusAdapter using positional Timestamp(...) — killed dashboard status consumption.

Both would have been caught by a test that ran OrchestratingProcessor.process() through a sink that performs x5f2 encoding, or an adapter test that fed a real Kafka message object into X5f2ToStatusAdapter.adapt.

Suggested approaches

Two options, not mutually exclusive:

1. Serializing test sink. Add a variant of FakeMessageSink that mirrors KafkaSink.publish_messages' serialization dispatch (service_status_to_x5f2 / job_status_to_x5f2 / self._serializer(msg)), but stores the resulting bytes instead of producing to Kafka. Existing LivedataApp tests can opt in and would catch this entire class of type drift for free.
2. Direct KafkaSink tests. A small test file using a fake confluent_kafka.Producer (just capturing produce() calls) to round-trip ServiceStatus/JobStatus through the real KafkaSink. Cheap and focused.

Option 1 gives broader coverage for free; option 2 is a targeted safety net. I'd suggest starting with option 1.

Related

• Fix service heartbeat crash: payload timestamp fields #847 (fix for both the backend heartbeat and dashboard adapter crashes)
• Kafka broker timestamps treated as ns instead of ms in 5 adapter sites #848 (ms-as-ns unit bug in five other adapter sites — same coverage gap)