Skip to content

UNOMI-948: Add PersistenceService.rangeQuery API#781

Merged
sergehuber merged 4 commits into
masterfrom
UNOMI-948-range-query
Jun 27, 2026
Merged

UNOMI-948: Add PersistenceService.rangeQuery API#781
sergehuber merged 4 commits into
masterfrom
UNOMI-948-range-query

Conversation

@sergehuber

Copy link
Copy Markdown
Contributor

For project managers

Unomi 3 needs a standard way to find customer profiles and events by numeric ranges—for example ages, scores, or date windows—when teams use either Elasticsearch or OpenSearch. This change adds that missing search capability to the product core so planned 3.x features can rely on it regardless of which search backend a deployment uses. Automated checks confirm basic range search works end-to-end; broader API test coverage is tracked separately on UNOMI-956.

Summary

  • Add PersistenceService.rangeQuery(...) to the persistence SPI
  • Implement range queries in Elasticsearch and OpenSearch persistence modules
  • Promote the existing in-memory test harness implementation to a proper @Override
  • Add PersistenceServiceIT smoke tests (numeric range + pagination) and register in AllITs
  • Strengthen unit-test totalSize assertions for in-memory range-query pagination

JIRA

  • UNOMI-948 — this PR
  • UNOMI-956 — follow-up: full PersistenceService integration test matrix

Test plan

  • mvn -pl persistence-spi install -DskipTests then mvn -pl services test -Dtest=InMemoryPersistenceServiceImplTest$RangeQueryTests
  • mvn -pl persistence-spi,persistence-elasticsearch/core,persistence-opensearch/core -am compile
  • mvn -f itests/pom.xml compile -DskipTests
  • CI integration tests (PersistenceServiceIT via AllITs suite)

Expose rangeQuery on the persistence SPI and implement it for Elasticsearch,
OpenSearch, and the in-memory test harness. Add smoke integration tests and
strengthen unit-test pagination assertions for totalSize.

Related: UNOMI-956 (full PersistenceService IT coverage follow-up).
@sergehuber sergehuber requested a review from Copilot June 25, 2026 14:37

This comment was marked as off-topic.

…earch

Elasticsearch used an exclusive upper bound (lt) while OpenSearch and the
in-memory test harness treated it as inclusive, so the same call could
return different results depending on the backend. Align Elasticsearch on
the inclusive semantics, guard both implementations against null from/to
so an unbounded side isn't serialized as a literal null, rename the SPI's
unused "s" parameter to "fieldName", and update the IT to assert the
inclusive boundary directly instead of working around the old mismatch.
testPurgeByDateDelegatesToPersistenceService and
testPurgeByScopeDelegatesToPersistenceService build ClusterNode fixtures
without setting lastHeartbeat, which defaults to 0. The real scheduler set
up in @beforeeach fires cleanupStaleNodes() with initialDelay=0, so it can
race the test and delete these fixtures as "stale" before the assertions
run, intermittently on CI. Apply the same clusterService.cancelScheduledTasks()
fix already used in testCleanupStaleNodes to both tests.
…lTest setUp

The previous fix (clusterService.cancelScheduledTasks() inside the two
purge tests) didn't actually close the race: cancelTask() only prevents
future executions, so if the zero-initial-delay task had already been
dispatched to the scheduler's thread pool before the test method's first
line ran, cancelling did nothing. setUp() was the one starting these tasks
unconditionally, before any test method body got a chance to run. None of
the tests actually need the tasks pre-started by setUp() — every test that
exercises scheduled-task behavior already calls clusterService.init()
itself, which starts them at the right time. Removing the eager start from
setUp() closes the race for all tests in the class, not just the two that
were observed failing.
@sergehuber sergehuber merged commit 8c5bfa2 into master Jun 27, 2026
8 of 9 checks passed
@sergehuber sergehuber deleted the UNOMI-948-range-query branch June 27, 2026 13:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants