chore: raise weaviate-client floor and test against Weaviate 1.39

[dudanogueira]

Related Issues

• None.

Proposed Changes:

Three related maintenance bumps for the Weaviate integration.

weaviate-client>=4.20 → >=4.23.0. To be straightforward about it: nothing in the integration currently needs an API newer than 4.20, so this is hygiene rather than a requirement. The reason to do it anyway is that the declared floor is the version CI actually exercises — the "lowest direct dependencies" step resolves to it — and 4.20 carries three bugs on paths this integration uses:

• 4.23.0 fixes collections.exists() in the async client swallowing non-404 errors and returning False. The async_client property calls exactly this, and on a swallowed error would try to re-create an existing collection.
• 4.23.0 fixes blocking of the event loop while the async client waits for Weaviate to become ready. Every run_async path goes through it.
• 4.21.2 fixes aggregate metrics returning 0/0.0 instead of None for empty result sets, which get_metadata_field_min_max() and the unique-value aggregates depend on.

No upper cap is added.

Test server 1.36.2 → 1.39.4. The integration suite was testing three minor versions behind, so nothing from 1.37, 1.38 or 1.39 was covered. This also moves off the Docker Hub image path to cr.weaviate.io to avoid pull rate limits in CI.

A readiness gate. docker-compose.yml gains a healthcheck and the workflow switches to docker compose up -d --wait. The container was previously started with no wait at all, immediately before the unit tests; that race is a plausible source of the flakiness the --reruns 3 --reruns-delay 30 retry policy currently masks.

How did you test it?

Reproduced the CI lowest-direct step locally, which resolves to weaviate-client==4.23.0, and ran hatch run test:unit against it — 81 passed. Restored the environment with hatch env prune afterwards.

Ran the full integration suite against Weaviate 1.39.4: 186 passed, 1 skipped. docker compose up -d --wait returns after ~11s with the container reported healthy.

hatch run fmt-check and hatch run test:types pass.

Notes for the reviewer

The healthcheck shells out to busybox wget, since the Weaviate image ships no curl or standalone wget. I verified it works on 1.39.4, but it does couple the compose file to an image internal. If you'd rather not, the alternative is a runner-side poll step in the workflow instead:

- run: timeout 120 sh -c 'until curl -sf localhost:8080/v1/.well-known/ready; do sleep 2; done'

Happy to switch to that — or to drop the client floor bump entirely and keep only the server bump, if forcing an upgrade on downstream users isn't worth the three fixes above.

Checklist

• I have read the contributors guidelines and the code of conduct
• I have updated the related issue with new insights and changes
• I added unit tests and updated the docstrings
• I've used one of the conventional commit types for my PR title

[CLAassistant]

All committers have signed the CLA.

[github-actions]

Hi @dudanogueira, thanks for your interest in contributing to Haystack! 🙏

⚠️ You currently have 4 open pull requests in this repository (#3957, #3955, #3954 and this one). Our review capacity is limited, so please hold off opening more PRs until we've had a chance to review your first 2 open PRs. This helps us give each contribution the attention it deserves. Thank you!

This is an automated message to help us keep the review queue healthy.

[github-actions]

Coverage report (weaviate)

This PR does not seem to contain any modification to coverable code.

[davidsbatista]

Looks good @dudanogueira - thanks for the update! obrigado :)