https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/ircd/batch.c?h=main 2026-06-04T02:33:53Z 2026-06-04T02:33:53Z Ryan Schmidt 2026-05-23T03:14:45Z urn:sha1:b4e6069dd93b2abb4603d36a00250658363070f4 The previous API was too error-prone, as evidenced by the large amount of crash bugs discovered with it. New functions were added to response.h to more easily manage labeled-response state, and some state tracking was moved into core (such as CLICAP_RECEIVE_LABEL, which must only ever be on one client at a time). Because this tracking is now in core, cap_labeled_response needs to be a core module as having that bit unloaded will cause issues. m_batch was also moved into being a core module as more and more core things have depended on batch support existing (and more will depend on it in the future). m_list no longer re-uses remote response batches for SAFELIST, instead making use of new APIs to suspend a labeled-response batch and more easily resume it. Batch resumption was made more focused as well, to ensure that we don't accidentally lose batches due to setting outgoing_response_info to NULL. The free_response_batch takes a resumption pointer to avoid cases where we could introduce use-after-free by combining free+resume_response_batch. struct ResponseInfo now takes strduped pointers instead of directly holding the buffers, and some fields were merged into a flags field or omitted entirely due to new suspension/resumption support. This will have a minor positive impact on memory usage as we no longer need to allocate buffers for maximum-sized strings for every labeled-response. Finally, shorten the dictionary label for pending responses. It was overflowing its spot in STATS B, making the data after it misaligned. 2026-05-13T01:08:00Z Ryan Schmidt 2026-03-31T17:04:42Z urn:sha1:98976173e6cec7f36378fa78b112497d6ea88192 When allocate_batch_message is called on a batch containing valueless tags (i.e. tag value is NULL), the ircd would core because we attempted to call strlen on a NULL pointer. Properly detect NULL values and don't attempt to copy them. Additionally, misbehaving hooks may set tag keys to be NULL. While this is not documented or officially supported, other parts of the codebase detect NULL keys as an indication that the tag should be stripped; detect this as well and avoid copying those tags entirely in the newly-allocated batch message for consistency and to avoid spurious crashes. This crash is currently not exploitable because allocate_batch_message() is only called for client-initiated batches and batches sent s2s, of which there are currently none. 2026-05-13T01:08:00Z Ryan Schmidt 2026-03-31T16:50:43Z urn:sha1:2619d66a8a7ee5124824e45957ef51ebacde4feb - new struct ResponseInfo that keeps track of all relevant state for a labeled-response (whether local or remote) - event to clean up pending remote labeled-responses that we haven't gotten responses for (perhaps due to a bad network link with the remote server, or it doesn't have labeled-response loaded) - struct Batch grew a new field to track its labeled-response status - struct Client grew a new linked list to track pending remote labeled-responses for it, so we can abort them easily if the client disconnects - struct ListClient grew a new field to track labeled-response status for a SAFELIST iteration - remove arbitrary size limit on batch id generation; it will now fill the passed-in buffer according to the passed-in buffer size, leaving room for the null byte at the end. NULL fields indicate that no responses are being labeled. The actual population of those fields will happen in future patches; this one simply provides the core support needed. 2026-01-21T16:10:44Z Ryan Schmidt 2026-01-13T17:12:32Z urn:sha1:8162cbe9d4f350da87a6eff02d06c804889b0d5f The extension example_module was extended to introduce a new client-initiated batch type named test. This is primarily done to ease testing of the client-initiated portions of m_batch, but also serves as a useful sketch for how a module can register its own client-initiated batch types. The definition of struct BatchHandler was slightly modified to use a callback function to determine if nesting is allowed. The callback can additionally set a custom error message if desired when returning false. The len and messages list in struct Batch no longer include the start message, so a len of 0 indicates an empty batch. Because the start message is still allocated and saved off, adjust anything that impacts a client's pending_batch_lines by 1 to account for the implicit additional message. Empty batches now trigger the relevant batch handler. If a handler wants to no-op on empty batches, it can do so but this allows additional flexibility for handlers to still do something upon receiving empty client-initiated batches. 2026-01-21T16:10:44Z Ryan Schmidt 2025-10-25T00:59:22Z urn:sha1:4cc9be1ddf1e14fc76bf433e23a3d528424b60ca - Add "batch" client capability - Support sending netsplit/netjoin batches - Support receiving BATCH from clients and remote servers - Support for modules to define supported batch types for incoming batches - Add "message_handler" hook to override the handler for a particular incoming message - Add technical and user-facing documentation for batches - Add some more sendto_* overloads that support tags which were missing from the initial message-tags implementation but turned out to be needed 2016-04-16T16:05:00Z Elizabeth Myers 2016-04-16T16:05:00Z urn:sha1:7445ece1d136bdaa2dde8a97eac73f3316ff086c This needs more work, see https://github.com/ircv3/ircv3-specifications/issues/253 This reverts commit 23738912993a8debf007542c51aeff79588e35ca. 2016-04-15T21:50:43Z Elizabeth Myers 2016-04-15T21:50:43Z urn:sha1:23738912993a8debf007542c51aeff79588e35ca This also lays the groundwork for the netjoin batch type, but that isn't implemented yet. I don't like how some of this is implemented but it'll have to do for now... Compile tested, needs more testing.