[Bug]: Single burst edge case test giving unexpected results

[riverma]

Checked for duplicates

Yes - I've already checked

Describe the bug

When I ran through an edge case, specifically this one, I noticed that a higher number of download jobs were launched than expected by the system. Specifically, additional MGRS tile set references were observed to be matched by the system.

What did you expect?

Only two download jobs to be submitted, representing unique MGRS tile sets: MS_20_30 and MS_20_29

Reproducible steps

1. Go to INT-FWD Mozart
2. Run this command:

   python daac_data_subscriber.py query -c OPERA_L2_RTC-S1_V1 --release-version=3.0.0-rc.3.0 --job-queue=opera-job_worker-rtc_data_download --chunk-size=1 --processing-mode=reprocessing --native-id="OPERA_L2_RTC-S1_T020-041121-IW1_20231101T013115Z_20231104T041913Z_S1A_30_v1.0"

3. Observe the following log result

   [2024-04-16 17:23:11,211: INFO/run_query] len(results)=4
   [2024-04-16 17:23:11,211: INFO/run_query] results=[('MS_20_30$147', '1f5d746f-6565-481d-bde1-265ea41cc984'), ('MS_20_29$147', '24bb76e3-e990-4f4a-a69e-a670e12a7108'), ('MS_20_29$160', 'd8d44fd4-f7b6-4898-9824-c3a4d584dac8'), ('MS_20_30$160', 'd4213286-1a52-427b-a342-2ad2ee55e100')]

4. In step (3) above, we expect Len(results)=2 not 4.

Environment

• Version of this software: PCM 3.0.0-rc.3.0
• Venue: INT-FWD
• settings.yaml configuration:

  ...
  DSWX_S1_COVERAGE_TARGET: 1
  # Force DSWx-S1 processing of pending burst sets after X minutes, rather than waiting for additional data
  DSWX_S1_COLLECTION_GRACE_PERIOD_MINUTES: 0
  ...

[philipjyoon]

Note that the acquisition time cycles were 147 and 160. At most these two should be 1 apart. It's not possible to have 13 cycles away for a single RTC granule triggering.

[hhlee445]

@chrisjrd I checked with latest develop branch, it triggers 3 download jobs, not 2.
coverage_results_short={-1: ['MS_20_30', 'MS_20_31', 'MS_20_29']}