Consultation with Nate Lust has indicated that my strategy for the two-stage ISR will work fine after DM-21904.  However, this means that until that ticket is finished, these two stages will need to be run in separate pipelines.  I've added a ticket to resolve this, and after rebasing and testing the current code with the split pipelines, will merge this ticket.

Description of the middleware issue:

IsrTaskConnections.ccdExposure is now an pipeBase.connectionType.Input.  Passing the same dataset type to this and IsrTaskConnections.crosstalkSources causes the quantum graph generation to fail, because that is a PrerequisiteInput, and the same dataset is not allowed to have different connectionTypes.  Switching crosstalkSources to an Input causes a different problem: we need to select all existing inputs that have the same dataId as the ccdExposure, but without the "detector" constraint (to load the full focal plane of possible crosstalk source exposures).  This was being done with a lookupFunction that could remove the "detector" constraint before querying the butler.  This method only exists for PrerequisiteInput.

To resolve this ticket, I am keeping crosstalkSources as a PrerequisiteInput, and removing the two-step pipeline definition for obs_decam.  This breaks inter-chip crosstalk in gen3, which will have to wait for improvements in quantum graph generation that are already planned.  DM-25348 will contain the inter-chip fix, and will be done once the middleware tickets merge.

Understood, thanks for the update. I'm a little sad that gen3 inter-CCD crosstalk won't happen after all on this ticket, but you've done a lot of important work here to get gen2 to work as before as well as implementing gen3 intra-CCD crosstalk. Happy to take a final look if there have been significant code changes since the initial review, just let me know.

This isn't the only situation where we will need a separate pipeline to run to generate "prerequisite" data products, so I'm glad that's being handled in DM-21904! I'd be happy to review the new followup DM-25348 when it's ready, and we'll make do without gen3 inter-CCD crosstalk for now.

Christopher Waters so what does this mean for running DECam in Gen 3? Will we still have crashes as originally reported, or will we simply have lower-quality outputs because not all of the crosstalk has been corrected?

There should be no crashes from crosstalk with DECam in Gen3 (at least, I am unable to find inputs that crash on my ticket branch runs).  The outputs will be lower quality as they are not corrected for inter-chip crosstalk, but will have the intra-chip (amp-to-amp in the same detector) corrected.