Fix ReceivedChunks::spill() throwing on control messages

[Matt711]

ReceivedChunks::spill() iterated all chunks in the postbox and called chunk.data_memory_type() as the left operand of ||, so C++ evaluated it before the size == 0 guard could short-circuit. Control messages (finish tokens) have no data buffer by design (data_ == nullptr), so data_memory_type() hits RAPIDSMPF_EXPECTS(data_, "data buffer is not set") and fails.

The fix is to reorder the condition to check size == 0 and !is_data_buffer_set() first, so data_memory_type() is only called when there's actually a buffer to inspect.

More context: xref rapidsai/cudf#21750

Details

This originally came up when running TPC-DS Q67 with --executor streaming --runtime rapidsmpf --spill-to-pinned-memory --n-workers 1. The query was running under memory pressure (that's the point of --spill-to-pinned-memory). During the shuffle phase, partition_and_pack called br->reserve_device_memory_and_spill() internally, which triggered the spill manager to invoke all registered spill callbacks. This includes the one registered by ShufflerAsync. That callback called ReceivedChunks::spill(), which iterated over chunks in the postbox. By that point, finish tokens (control messages) had already arrived in the postbox, and calling data_memory_type() on one threw because data_ was null.

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[Matt711]

/ok to test bda7ee3

[Matt711]

/ok to test 7606a43

[madsbk]

Thanks @Matt711, good catch!