$5 says that adding `doWriteWarpedExp: True` to ap_pipe/ApPipe.yaml under the imageDifference config will fix this.

I believe the problem is solved in DM-29338, which I just put in review with Ian Sullivan.

What's the status of this ticket? In particular, do we know what caused it to fail starting June 3?

I merged DM-29338 on Friday, so if this problem doesn't happen again, it is fixed. I believe the issue was imageDifference not persisting the warped exposure which diaPipe expects as an input (both for regular sources and fake sources). 

I think I found the (current) problem. The workaround on DM-29338 caused some of the input/output connections, but not others, to stop using fakesType, so when ApVerifyWithFakes.yaml updates fakesType, some of the outputs no longer match other tasks' inputs. This manifests as

RuntimeError: Error finding datasets of type deepDiff_diaSrc_schema in collections [ap_verify-output]

(where the registered dataset type is fakes_deepDiff_diaSrc_schema).

I saw on Slack that this is supposed to be a workaround for DM-30210, but I can't find any contracts that use connection names rather than template parameters (and said contracts don't catch the problem because they don't test the actual connection names...). Can you point me to the lines that forced you to use explicit connections in ApPipe.yaml?

What forced us to use explicit connections was an empty quantum graph (various data types not being found) when we didn't have them. Just setting `coaddName` is insufficient if there is something constructed from `coaddName` that appears as a contract.

So there is a new fakes-related failure now that I've merged DM-29338? Sorry I missed that.

I discussed with Meredith Rawls offline and we agreed that I'd expand the DM-29338 hard-coding to include all the fakesType/coaddName connections, including ones like imageDifference:connections.outputSchema that had been left alone until now. I'll tag with a comment that this is temporary until DM-30210 is fixed.

Thanks for tweaking the language: it makes more sense now.

We should probably have a ticket about removing the `if self.config.coaddName == 'dcr':` in `ImageDifferenceTask:runQuantum`, and/or replacing it with the Connection `coaddName` (or doing that particular configuration in the Config or Connections, if its more appropriate there).