PACE OCI TRGAS NRT: CMR collection version mismatch and missing granules after 14-Aug-2026

[zephyrion]

Hello,

I am using the PACE OCI Level-2 NRT products in an automated processing workflow and have encountered what appears to be a collection version/CMR metadata issue with `PACE_OCI_L2_TRGAS_NRT`.

The TRGAS NRT files are still being generated and are available from the OB.DAAC Direct Data Access service. For example, V3.0 TRGAS files are available for **16-Aug-2026** under:

https://oceandata.sci.gsfc.nasa.gov/directdataaccess/Level-2/PACE-OCI/2026/16-Aug-2026/

The files have names such as:

`PACE_OCI.20260816Txxxxxx.L2.TRGAS.V3_0.NRT.nc`

and the NetCDF files themselves contain:

`processing_version = "3.0"`

However, I noticed an inconsistency in the CMR collection metadata.

Using:

`cmfetch collection --shortname PACE_OCI_L2_TRGAS_NRT --output short`

I get:

* `revision_id`: **19**
* `revision_date`: **2026-08-14**
* `version`: **3.1**

I then tested CMR granule searches. The behavior is interesting:

* When the temporal search starts on **2026-08-14 or earlier**, CMR returns the expected TRGAS V3.0 granules.
* When the temporal search starts on **2026-08-15 or later**, CMR returns **no granules**.
* Meanwhile, the corresponding V3.0 granules are present in the OB.DAAC Direct Data Access archive, including on 15-, 16- and 17-Aug-2026(today).

For example, the situation can be summarized as:

```text
CMR collection:
short_name = PACE_OCI_L2_TRGAS_NRT
revision_id = 19
revision_date = 2026-08-14
version = 3.1

CMR granule search:
start <= 2026-08-14 → granules returned
start >= 2026-08-15 → no granules returned

OB.DAAC Direct Data Access:
2026-08-15 → V3_0 TRGAS files available
2026-08-16 → V3_0 TRGAS files available

NetCDF:
processing_version = 3.0
```

This makes me suspect that the CMR collection metadata was changed to version 3.1 in revision 19 on 14-Aug-2026, while the operational TRGAS NRT processing is still producing V3.0 files.

Could you please clarify:

1. Was `PACE_OCI_L2_TRGAS_NRT` intentionally changed from V3.0 to V3.1 in CMR on 14-Aug-2026?
2. If so, should the operational NRT files have changed to V3.1 as well?
3. If the operational product is still supposed to be V3.0, could the CMR collection metadata/indexing be corrected so that the newly generated V3.0 granules after 14-Aug-2026 are discoverable?

This is particularly important for automated NRT processing. My workflow uses CMR temporal/spatial queries to identify the required granules and then downloads the corresponding files from the OB.DAAC Direct Data Access service. Therefore, although the data files themselves are available, the missing CMR granules prevent the normal automated discovery workflow from working.

Thank you for looking into this issue.

Best regards,
Jeon-Teo

[OB.DAAC-EDL - amscott]

Hello! You caught an upload error in metadata that *should not* have been accepted by the CMR system. The metadata has since been corrected to say 3.0 which is the correct version. Thank you for reporting.

[zephyrion]

Thank you for the quick fix and reply, now my operational pipeline works as well as some days ago.
Thanks again :)