Rollback on failed batch insert leaves orphaned records

During batch insert operations, if an error occurs, the Storage service attempts to roll back the latest changes in both the blob storage and the metadata store.

The rollback in blob storage involves completely removing the associated record body:

However, the metadata rollback only updates the records, rather than removing them:

As a result, if the failed records were the only versions, they become dangling entries, metadata without corresponding blobs.

This makes them unretrievable:

• You can’t fetch them by ID

curl --location 'https://community.gcp.gnrg-osdu.projects.epam.com/api/storage/v2/records/osdu:test:test-error-handling:3' \
--header 'Data-Partition-ID: osdu' \
--header 'frame-of-reference: units=SI;crs=wgs84;elevation=msl;azimuth=true north;dates=utc;' \
--header 'Authorization: Bearer '

{
    "code": 404,
    "reason": "Record Not Found",
    "message": "No version available for this record."
}

• Batch retrieval won’t return them either

curl --location 'https://community.gcp.gnrg-osdu.projects.epam.com/api/storage/v2/query/records:batch' \
--header 'Data-Partition-ID: osdu' \
--header 'frame-of-reference: units=SI;crs=wgs84;elevation=msl;azimuth=true north;dates=utc;' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer ' \
--data '{
    "records": [
        "osdu:test:test-error-handling:3"
    ]
}'

{
    "records": [],
    "notFound": [
        "osdu:test:test-error-handling:3"
    ],
    "conversionStatuses": []
}

We need to update the rollback procedure to remove metadata if a record has only one version and the Storage service fails to ingest it.