breaking: SendMessages TCP response changed from void without compatibility negotiation

[atharvalade]

Problem

SendMessages in TCP/binary protocol used to return an empty success response.
Now it returns a payload (base_offset, partition_id) without a compatibility gate.

Why this is critical

Older clients and mixed-version deployments may mis-handle this wire change.
This can cause unexpected failures or inconsistent behavior.

Where

• core/server/src/binary/handlers/messages/send_messages_handler.rs
• core/binary_protocol/src/responses/messages/send_messages.rs

Expected

Either:

1. Keep old behavior for current protocol version, and add new response in a versioned way, or
2. Add explicit protocol negotiation/feature flag and update all SDKs together.

@hubcio @spetz thoughts?

[hubcio]

file core/server/src/binary/handlers/messages/send_messages_handler.rs doesn't contain anything you mentioned

file core/binary_protocol/src/responses/messages/send_messages.rs doesn't exist in the codebase.

could you elaborate...?

[lukaszzborek]

I think he was talking about #3101
@atharvalade i think you should write it under the pr

[hubcio]

before 1.0.0 protocol versioning is not (yet) important. we break things constantly, the thing is that what's merged in the codebase has to work for all SDKs.

we will address that using Login command, in which each sdk will send both its version AND version of binary protocol. on that basis, server will be able to reject / accept individual connections. (server will evaluate binary compatibility of each client, similar to kafka magic but not in every single message, just at login).