I am going to need to think about this one a little bit, because it is actually working as intended. The configuration values are being set on the config object, which is later used to format a connections class. You are not actually looking at the connections class, just the info that goes into constructing one. In other words, someone might change the the connections name to a different format template, and want to validate the template before substitution (though of course that would be less frequent, and so we should probably angle toward the least surprise even if it makes for different execution paths)

a workaround (verbose) for now can be:

- imageDifference.connections.ConnectionsClass(config=imageDifference).subtractedExposure.name==\

  transformDiaSourceCat.connections.ConnectionsClass(config=transformDiaSourceCat).diffIm.name

I will try to think of the right way to handle this in the checker going forward

FWIW, in the AP configs we wrote the analogous contract as

imageDifference.connections.coaddName == transformDiaSrcCat.connections.coaddName

This approach won't catch problems if you override connections to not use the template, but is much more portable when you don't (not least because you don't need to enumerate every single connection). Is this a contract style that's discouraged in general?

Bumping this, as the continued requirement to manually set a bunch of things to, e.g., `goodSeeing` (when that's your desired coaddName flavor instead of `deep`) in a pipeline yaml wasted a couple hours of my time today.

Note that this problem does not apply to pipeline parameters – you can mix parameterized and non-parameterized fields in contracts.