I'm not sure that there have been many successful extensions of OpProcessor (though you describe yours as doing something for you). I've mostly seen that providers have found the extensions points insufficient for their needs and end up in a fork or at the netty level. There's something not right there in their abstraction for most cases. I think with the move to pure HTTP in 4.x it made sense to divest the server of some of the layers it had. Ultimately, I think extension points for the server in 4.x are up for discussion. afaik, no decisions have been made as to what the alternative will be.
On Mon, Nov 10, 2025 at 3:17 AM Andrii Lomakin <[email protected]> wrote: > Good day. > > Could you clarify the reasoning behind the removal of OpProcessors support > in TP 4.0 and what extension mechanics are proposed as an alternative? > > Example of how we use OpProcessors for protocol extensions: > > 1. Extension of core OpProcessors - during TX processing, IDs of our > elements undergo two phases: temporary and permanent. During which their > values are changed. Because query results are streamed, we send additional > metadata that maps temporary IDs to the permanent ones to keep client data > in sync in the final response Frame. > 2. We provide our own OpProcessor, which handles commands related to the > management of database instances present on the server. > > Which mechanics are provided for such and similar extension points in TP 4? >
