Detect that this production’s own summarypages run has finished.
The base Pipeline.detect_completion() is an unconditional no-op
(always falsy). Once this production’s HTCondor job has exited and
asimov’s monitor loop is no longer tracking a job id for it,
asimov monitor’s no-job-id branch
(_handle_no_condor_job in asimov’s monitor_states.py) relies
entirely on this method to decide whether to mark the production
finished; without an override here it always finds this falsy
and repeatedly logs “is stuck; attempting a rescue” – forever,
since the base resurrect() is an equally unconditional no-op
that never raises, so the production never progresses no matter how
long or how often it’s polled, even once a genuine, correctly
labelled posterior_samples.h5 already exists on disk.
Delegates to detect_completion_processing(), which already
implements the right check for this pipeline’s own output: that
posterior_samples.h5 exists, is readable, and (for a
SubjectAnalysis) contains every expected analysis’s label as a
top-level group.
That check alone is unsound while a removal or rename (see
_submit_subject_analysis_removal/rename_analysis) is
in-flight: it only checks that expected labels are present, never
that anything unexpected is absent, so an untouched metafile from
before a removal already satisfies “surviving labels present” –
it would look complete before the summarymodify/summarypages
chain has even run, let alone finished. So when a chained operation
is pending (tracked via the pesummary_pending_chain_labels meta
key), this first requires the chain’s own completion marker to
exist – proof every step of that script actually ran, not just the
first – before finalising resolved_dependencies to what the
chain was renaming/removing towards and falling through to the
normal check above.