That is the goal but since the artifacts are still created at the radio part there is no access to observation id. It is something we want but will be implemented later.
Ah yes, this is because IQ files (and some other things) are created outside the flowgraphs with the use of ZMQ publishers and subscribers. The file was always saved because the IQ zmq subscriber was running regardless of the ENABLE_IQ_DUMP option.
Very interesting discussion.
The move from direct file handling inside the radio/flowgraph part to a ZMQ-based artifact path makes sense to me, especially if the long-term goal is to decouple signal processing from downstream artifact handling.
Small thought: one thing I would watch carefully is the metadata boundary.
If IQ files, frames, images or other artifacts are produced outside the radio part, the artifact itself may eventually need a minimal context envelope or companion manifest: artifact type, sample format, timestamp source, sample rate, center frequency, producer stage, and observation/station identifiers when they become available.
That would avoid downstream scripts relying only on filename conventions, while still keeping the radio part clean and generic.
The observation ID question raised by PE0SAT seems especially important here. Even if it cannot be added at the radio layer today, it feels like the right piece of context to attach later at the client/artifact-handling boundary.