fix(data-quality): don't fail logical-suite adds when revisions don't read back - #31640
fix(data-quality): don't fail logical-suite adds when revisions don't read back#31640mohityadav766 wants to merge 1 commit into
Conversation
… read back prepareLogicalSuiteRelationshipChange advanced the testSuitesRevision rows for the added test cases and the suite, then re-read them and threw IllegalStateException if the read-back was short. That read-back is a snapshot read inside the flush transaction, so concurrent writers on the same rows can make it return fewer rows than were just advanced — MySQL's default REPEATABLE READ far more readily than Postgres' READ COMMITTED. The throw rolled back membership rows that had persisted correctly and answered the caller with a 500. Revisions only order concurrent search writes, and every consumer already tolerates one it wasn't handed: EntityUpdateContext.forEntity falls back to empty, and TestCaseIndex/TestSuiteIndex re-read the revision at index time. So log the unresolved ids and carry on instead of failing the request. Turned integration-tests-mysql-elasticsearch red intermittently across unrelated PRs, e.g. TestSuiteResourceIT.test_createLogicalTestSuiteAndAddTestCases and TestCaseResourceIT.test_concurrentLogicalSuiteTestAddsPreserveEverySearchTest, where all six concurrent PUTs to /dataQuality/testCases/logicalTestCases returned 500 in the same 30ms window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
❌ PR checklist incompleteThis PR cannot be merged until the following are addressed on its linked issue:
The fields live on the linked issue in the Shipping project (open the issue → right sidebar → Projects). After you set them, re-run this check (or push a commit) — issue/project changes do not re-trigger it automatically. Maintainers can bypass this check by adding the |
Code Review ✅ ApprovedRemoves the restrictive read-back validation in TestCaseRepository.prepareLogicalSuiteRelationshipChange to prevent spurious 500 errors during concurrent logical suite test additions on MySQL. No issues found. OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Was this helpful? React with 👍 / 👎 | Powered by Gitar — free for open source |
There was a problem hiding this comment.
Pull request overview
This PR fixes intermittent failures when adding test cases to logical test suites by removing strict “revision read-back must match” guards that can fail under concurrent writers (especially on MySQL REPEATABLE READ). Instead of throwing and rolling back otherwise-correct relationship writes (causing 500s), the repository now logs unresolved revision IDs and continues, relying on existing search-index behavior that can re-read missing relationship revisions.
Changes:
- Stop throwing on incomplete revision read-back in
prepareLogicalSuiteRelationshipChange; log WARNs instead. - Make the logical-suite relationship revision nullable and avoid passing a bogus
0Lgate to indexing (EntityUpdateContext.empty()when unresolved). - Add a unit test covering the “missing read-back rows” scenario to ensure membership changes still proceed.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/TestCaseRepository.java | Removes revision read-back hard-fail, makes suite relationship revision nullable, and avoids null revision entries when building update contexts. |
| openmetadata-service/src/test/java/org/openmetadata/service/jdbi3/TestCaseRepositoryTest.java | Adds a unit test asserting unresolved revisions don’t prevent membership-change publication and don’t gate indexing. |
Suppressed comments (1)
openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/TestCaseRepository.java:1468
- This record was widened from private to package-private for test access. Marking it as VisibleForTesting would document that it is not intended as part of the repository's public surface area.
record LogicalSuiteRelationshipChange(
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| LogicalSuiteRelationshipChange prepareLogicalSuiteRelationshipChange( | ||
| UUID testSuiteId, List<EntityReference> testCaseReferences) { |
|
closing as covered by #31569 |
Describe your changes
TestCaseRepository.prepareLogicalSuiteRelationshipChangeadvanced thetestSuitesRevisionentity_extensionrows for the added test cases and the suite, immediately re-read them, and threwIllegalStateException("Failed to persist every test suite relationship revision")if the read-back returned fewer rows than were advanced.That read-back is a snapshot read issued inside the
flushInOneTransactiontransaction. Under concurrent writers on the same revision rows it can come up short — MySQL's default REPEATABLE READ far more readily than Postgres' READ COMMITTED (nothing inconf/or the Jdbi setup overrides either default). The throw then rolled back theentity_relationshiprows that had persisted correctly and answered the caller with a 500.The guard was never load-bearing. Revisions only order concurrent search writes, and every consumer already tolerates one it wasn't handed:
EntityUpdateContext.forEntityreturnsEMPTYfor an absent idSearchIndexHandlerfalls back to the ungatedonEntityUpdatedpathTestCaseIndex/TestSuiteIndexre-read the revision themselves, defaulting to0LSo this logs the unresolved ids at WARN and carries on. An unresolved revision now costs one extra read at index time instead of losing the user's write.
Also:
LogicalSuiteRelationshipChange.relationshipRevisionbecomes nullable, andupdateLogicalTestSuitepassesEntityUpdateContext.empty()rather than a bogus0Lthat would gate the suite's own index update.addAllTestCasesToLogicalTestSuiteskips null revisions when building its per-batch map —EntityUpdateContext'sMap.copyOfrejects null values.Why this matters
This has been turning
integration-tests-mysql-elasticsearchred intermittently on unrelated PRs (#31526, #31527, #31540 all hit it; #31538 and #31543 didn't).integration-tests-postgres-opensearchstays green throughout. In the #31526 run all six concurrentPUT /api/v1/dataQuality/testCases/logicalTestCasescalls fromtest_concurrentLogicalSuiteTestAddsPreserveEverySearchTestreturned 500 inside the same 30 ms window, with no deadlock, lock-wait timeout, or pool error in the log.Affected tests:
TestSuiteResourceIT.test_createLogicalTestSuiteAndAddTestCasesTestSuiteResourceIT.test_deleteLogicalTestSuiteKeepsTestCasesTestSuiteResourceIT.test_summaryTotalIncludesUnexecutedAndExcludesDeletedTestsTestCaseResourceIT.test_concurrentLogicalSuiteTestAddsPreserveEverySearchTestTestCaseResourceIT.test_bulkAddTestCasesToLogicalTestSuiteByIdsTestCaseResourceIT.test_bulkAddAllTestCasesWithExcludeIdsIntroduced by #30120.
Type of change
Tests
TestCaseRepositoryTest.unresolvedRevisionsKeepTheMembershipChangedrivesprepareLogicalSuiteRelationshipChangewith a deliberately short test-case read-back and a missing suite revision, and asserts the change still carries the membership references plus the revisions that did resolve.Verified RED → GREEN — with the two throws restored the new test reproduces the exact CI error:
and with the fix:
mvn -pl openmetadata-service spotless:checkclean.The existing ITs above are the end-to-end check — they should stop flaking on the MySQL lane.
🤖 Generated with Claude Code
Greptile Summary
This PR prevents logical-suite membership writes from rolling back when transactional revision read-backs are incomplete.
Confidence Score: 5/5
The PR appears safe to merge, with no actionable correctness or security failures identified.
Missing revisions flow through existing index-time re-reads and relationship-preserving or revision-gated search updates, while transactional revision upserts continue to surface genuine persistence failures.
Important Files Changed
Sequence Diagram
Reviews (1): Last reviewed commit: "fix(data-quality): don't fail logical-su..." | Re-trigger Greptile
Context used: