check_vector: DQV stops the pipeline before any further processing
During the October O2 replay, the replayed GW170817 event was vetoed with the DQV
label by the L1 glitch ~1 second before the event time 1. In theory, during O3, all pipelines will be using gated h(t), which should mean that these glitches are gated out and hence the DQ-DMT_VECTOR checks will be redundant. In practice, it's unclear if all pipelines will really be using such gating.
To resolve this, should the DQV
label allow the rest of the pipeline to run, only stopping the final sending-out of GCNs? That way, an intervening human would be able to evaluate the rest of the data and send off the GCN if the veto is deemed unimportant.
Some possible implementations:
- Move the
check_vectors
task to right before the GCN-sending task. One issue with this is that if the preceding tasks take too long, the llhoft frames will have disappeared from the/dev/shm/
buffer, and the check_vectors task will no longer work. - Keep the
check_vectors
task where it is in the pipeline, but store the overall state somewhere, and check this overall state before the GCN is sent.