Ensure correct ordering for tests that rely on Elasticsearch response order

Description:

One of the test scenarios for as-ingested-coordinates expects that the natural ordering of the Elasticsearch response remains consistent, even when an explicit order is not provided.

It assumes that records will appear in the response sorted by ID:

"id": "osdu:virtual-properties-Integration:testIngest1"
...
"id": "osdu:virtual-properties-Integration:testIngest2"
...
"id": "osdu:virtual-properties-Integration:testIngest3"

We've noticed that in one environment, the ordering has changed and now appears as follows:

"id": "osdu:virtual-properties-Integration:testIngest2"
...
"id": "osdu:virtual-properties-Integration:testIngest1"
...
"id": "osdu:virtual-properties-Integration:testIngest3"

Tests fail because they pick only the first record from the Elasticsearch response and expect to find a property that is only present in the record with ID osdu:virtual-properties-Integration:testIngest1

To ensure tests work consistently across environments, we've explicitly added ordering while keeping changes minimal.

How to test:

Locally and in the pipeline.

Changes include:

  • Refactor (a non-breaking change that improves code maintainability).
  • Bugfix (a non-breaking change that solves an issue).
  • New feature (a non-breaking change that adds functionality).
  • Breaking change (a change that is not backward-compatible and/or changes current functionality).

Changes in:

  • Common code

Dev Checklist:

  • Added Unit Tests, wherever applicable.
  • Updated the Readme, if applicable.
  • Existing Tests pass
  • Verified functionality locally
  • Self Reviewed my code for formatting and complex business logic.

Other comments:

Any comments to approvers here

Merge request reports

Loading