Fix SWAPI integration tests

[leowerneck]

Change Summary

Closes #171, closes #172, closes #174.

Overview

• Fixed subprocess-spawned imap_l3_data_processor.py not inheriting the parent test's DATA_DIR, causing it to look for staged inputs in the wrong place.
• Added the missing imap_swapi_l3b_20260101_v001.json dependency fixture, which was never checked.
• Pinned SWAPI L3a fixtures to the correct science/ancillary file revisions.

Testing

Run:

uv run --with pytest pytest tests/integration/test_swapi_processor_integration.py

passes. Also verified the fix is robust to an arbitrary ambient IMAP_DATA_DIR (the original bug in #171):

IMAP_DATA_DIR=/tmp uv run --with pytest pytest tests/integration/test_swapi_processor_integration.py

Both pass identically.

[Copilot]

Pull request overview

Fixes SWAPI integration tests by aligning subprocess data paths and correcting dependency fixtures.

Changes:

• Passes the staged data directory to processor subprocesses.
• Adds the missing L3b dependency manifest.
• Pins SWAPI and MAG fixtures to correct revisions.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tests/integration/test_swapi_processor_integration.py	Aligns subprocess data paths and revised L2 fixture lookup.
tests/integration/test_data/swapi/imap_swapi_l3b_20260101_v001.json	Adds the missing L3b dependencies.
tests/integration/test_data/swapi/imap_swapi_l3a_pui-he_20260101_v001.json	Pins revised SWAPI science data.
tests/integration/test_data/swapi/imap_swapi_l3a_proton-sw_20260101_v001.json	Pins revised SWAPI science data.
tests/integration/test_data/swapi/imap_swapi_l3a_alpha-sw_20260101_v001.json	Pins revised SWAPI and MAG science data.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[jtniehof]

Minor comments, except that test_alpha_sw_with_production_data still fails OMM:

                try:
>                   numpy.testing.assert_allclose(
                        actual_value, expected_values[key], rtol=rtol, atol=atol, err_msg=key
                    )
E                   AssertionError: 
E                   Not equal to tolerance rtol=0.001, atol=0
E                   alpha_sw_density
E                   Mismatched elements: 1 / 1 (100%)
E                   Max absolute difference among violations: 0.00503448
E                   Max relative difference among violations: 0.03190463
E                    ACTUAL: array(0.162832)
E                    DESIRED: array(0.157798)

/home/jnik/work/scm/imap_L3_processing/tests/integration/test_swapi_processor_integration.py:194: AssertionError

Does this look like something you've come across in creating this fix (in which case maybe there's some lurking "wrong file" thing), or do I need to go chasing "from scratch"?

[jtniehof]

I'm a little worried about how these integration tests are tied to the current state of the archive, but that's sort of inherent to the nature of an integration test. Something to keep in mind if we ever clear out old unreleased versions. No changes here, just raising awareness.

[jtniehof]

...how on Earth did this even pretend to work before....

[jtniehof]

Fortunately this isn't a very complicated dependency setup, so this all falls out fine.

This is the old format of the dependency json...the new one has one list for dependency and one for the version info. I wonder if our underlying infrastructure will at some point stop supporting this, and from the point of view of integration test we probably should be testing the new format?

[jtniehof]

This might be an imap-data-access or sds-data-manager issue, because I thought we had decided that passing a single version would be interpreted as the minor version (because it wasn't resetting to zero on a major version bump). If I just imap-data-access download imap_swapi_l2_sci_20260101_v001.cdf, I get a 404, not v001.0008 (which based on #174 is I think what was downloading?) So is there something different in the way we're handling things in processing?

I don't think that affects your PR; this is the correct fix. But it makes me wonder if we're missing something elsewhere, even if it's just properly documenting the behavior.