MakeDirectWarpTask.run modifies input sky_map object in place (unexpected side effect on sky_info.bbox)

Support
#1

Description

While testing deep coadds built from visit_images with injected simulated lensing, we identified a potential unexpected side effect in MakeDirectWarpTask, defined in:

  • make_direct_warp.py
  • Method run (around line 337)

During our tests, we observed that calling run() modifies part of the original sky_map object passed as an input parameter. In particular, the field:

sky_info.bbox

appears to be overwritten in place.

This behavior propagates back to the original object (i.e., it is not a copy), suggesting that the task mutates its input arguments.

Why this is unexpected

The official documentation for MakeDirectWarpTask.run does not mention that the input sky_map (or sky_info) object may be modified in place:

  • LSST Pipelines API docs (v28.0.2)
  • DP1 tutorial notebook 105-1

From the documentation, we expected run() to behave functionally (i.e., return new data products without mutating its inputs), or at least clearly document any in-place modifications.

Minimal example (summary)

In our notebook (attached below), we:

  1. Store the initial value of sky_info.bbox
  2. Call MakeDirectWarpTask.run(…)
  3. Re-inspect the same object
  4. Observe that sky_info.bbox has changed

This suggests that the input object is being modified by reference inside run() (possibly also in runQuantum() or similar task structures).

Questions

  1. Is this in-place modification of sky_map / sky_info intentional?
  2. If so, should this behavior be documented explicitly?

Additional material

We attach:
• A notebook demonstrating the observed behavior and highlighting the section of the code where the modification appears to occur.
Unexpected_Behavior(1).ipynb (2.1 MB)

•	The make_direct_warp.py module (as accessed in December 2025), for reference and reproducibility

make_direct_warp.py (38.3 KB)

#2

This is unintentional and a bug; thanks for reporting it. We probably hadn’t noticed because we essentially always run this task as a PipelineTask, in which the those objects are loaded from disk, used by the task, and then discarded.

#3

Hi Jim,

Thanks for the clarification and for confirming that this is indeed unintentional.

That makes sense, if the task is typically executed as a PipelineTask, where the objects are loaded from disk and discarded afterward, this kind of side effect would be very difficult to notice in normal production workflows.

In our case, we are invoking MakeDirectWarpTask.run() directly and reusing the same sky_map / sky_info object across multiple calls (e.g., during testing with injected simulated lensing). That is how we detected that sky_info.bbox was being modified in place.

In our notebook, we propose some possible solutions. Please let us know if we can help further.

Best regards