What purpose does the `isnan(darkScale)` check serve? HSC doesn't set darkTime on its darks, and we've been relying on the VisitInfo pointer being null (instead of VisitInfo being default constructed), which is breaking now that I've made calibrations be ExposureF. If the dark's darkTime is NaN, shouldn't we always use a scale of 1?

Paul Price: you originally made the commit that did this check for DM-9004; have HSC calibs always been missing this value, and if so, how did it work after that ticket?

Christopher Waters: you made the additional check of whether VisitInfo exists for DM-16467: do you recall why you made that change? It was part of a much bigger commit, so the commit message isn't helpful.

I think the context of RFC-274 (DarkTime should default to the ExposureTime) would be helpful in understanding this.

I assume the ObservationInfo that populates VisitInfo is correct for HSC darks (the translator uses EXPTIME)? Is the debate here saying that for darks there is no attempt to create a VisitInfo even though we could do so?

Tim Jenness: that's a good way to phrase it. Until now, we were reading some (obs-package dependent as to which) calibrations as Image or MaskedImage, and they got turned into Exposures via `isrTask.ensureExposure()`. With my changes on DM-22655, we're now reading them as Exposure, so we can start filling out ExposureInfo and VisitInfo for Calibrations.

I've worked around this in DM-22655, as gen3 now treats calibrations as Exposure. I wouldn't say this is "fixed" or "done" yet though. We'll want to decide how to manage this: the ultimately correct behavior is to fill out this value in ObservationInfo->VisitInfo, and then reinstate some more rigid checks in ISR (or even earlier?). Whether we can do that without updating cp_pipe is another question (do we even have the necessary data in our existing calibrations?).

I believe I added the check because the VisitInfo was None (possibly only in the gen3 case based on the ticket), and so checking getDarkTime was raising an error.

 I'll be 100% happy if we assume all calibrations are full exposures in gen3/in the future.  I'm don't know how we currently assign ObservationInfo.VisitInfo for coadd products (which is essentially what calibration products are), but having those explicitly set values we now assume are defaults isn't a bad thing.