fix: async geo index race in the create-objects test, agents 1.8.0, and the Java 1.39 compat cell - #515
Merged
Merged
Conversation
The search_mode.py snippet passes effort= to QueryAgent.search(), which 1.7.0 does not accept. 1.8.0 adds it. The pin already allowed the newer release; the lockfile was simply resolved before it existed.
The Python lane failed on a bare AssertionError at the geo-range check in _includes/code/howto/manage-data.create.py (CI run 31718384134). The rendered example is correct; the test scaffolding after the WithGeoCoordinates markers was racing the index. A geo property is backed by its own index, and the test instances run with ASYNC_INDEXING enabled, so that index is filled in the background. Measured against local servers with ASYNC_INDEXING=true, the just-inserted object becomes visible to a within_geo_range filter after roughly 0.5 to 1.3 seconds: immediate on 1.38.0, 1.38.3 and 1.38.4, delayed from 1.38.5 onward, including 1.38.7 and 1.39.0. With ASYNC_INDEXING=false it is immediate on every version tested. main pins the test server at 1.38.0 and this branch pins 1.39.0, which is why the race only surfaces here. Add a bounded readiness wait before the assertion, mirroring the pattern already used in _includes/code/howto/search.filters.py, and clear the Publication collection first so the exact count cannot pick up an object left behind by an earlier failed run. The assertion stays exact and the rendered block is unchanged. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
java-client 6.3.1 (tag 6.3.1, no v prefix, published 2026-08-13) adds the AND_CROSS BM25 operator, hybrid diversity selection and multi2vec-twelvelabs support. multi2vec-twelvelabs is served by Weaviate 1.39.0 and is absent from 1.38.7, and AND_CROSS needs 1.37.15, 1.38.8 or 1.39.0, so 6.3.1 is the 1.39 client. Link built like the neighbouring 1.38.x cell. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![orca-security-eu[bot]](https://avatars.githubusercontent.com/in/276244?s=60&v=4){kind=small}
There was a problem hiding this comment.
Orca Security Scan Summary
| Status | Check | Issues by priority | |
|---|---|---|---|
 Passed |
Secrets |  0  0  0  0 |
View in Orca |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three fixes for the failures in run 31718384134.
weaviate-agents1.8.0search_mode.pypasseseffort=toQueryAgent.search(), which 1.7.0 does not accept. 1.8.0 adds it, and the pin already allowed it. The lockfile had simply been resolved before 1.8.0 existed.Worth knowing for #483: that snippet was never wrong, and the parameter was never missing from the client. It was a stale lockfile.
The geo assertion was a write-visibility race, not a 1.39 regression
manage-data.create.pyfailed onassert len(response.objects) == 1after awithin_geo_rangefilter. The object inserts correctly and the true distance is about 404 m against a 1000 m radius, so the geometry was never in doubt.A geo property has its own index with an async queue, so under
ASYNC_INDEXINGthe filter does not see the write immediately. Measured across server versions with the same client:ASYNC_INDEXING=truefalseThe lag arrives at 1.38.5, not 1.39. CI only surfaced it now because
mainpins the test server at 1.38.0 while this branch pins 1.39.0.Fixed in the test scaffolding, not the snippet: a bounded readiness wait before the assertion, which the repo already does for the same reason in
search.filters.py. The assertion stays exact. The rendered example is outside the failing markers and is unchanged. A scaffolding-only collection delete was added because a failed run otherwise leaves an object behind and the rerun sees two.Java 6.3.1
The 1.39.x compatibility row's Java cell was a placeholder. Set to
6.3.1, matching the 1.38 cell's form.Caveat: 6.3.1's release notes list
AND_CROSS, hybrid diversity selection andmulti2vec-twelvelabs, which are 1.39 features. But its own CI matrix tops out at Weaviate 1.38.2 with no 1.39 entry, so the claim rests on feature evidence rather than the client's integration tests.Follow-ups, not addressed here
That geo filters are eventually consistent under
ASYNC_INDEXINGis reader-relevant and undocumented. The async-indexing docs describe background index building in vector terms only.Also unresolved: no geo or queue file changed between v1.38.4 and v1.38.5, so it is unclear what activated the queue. If the pre-1.38.5 synchronous behaviour was an unintended fallback, someone owning that code should say which side was the bug.