~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

Two serve tests wait for the index and the code shards to settle

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:tests/flaky-index-reads

What changes

private_repositories_indexed_here read the thread of an issue it had just filed through a helper that asserts a 200. The appview index does not have a new issue until its space sync finds it, so the first poll could get a 404 and panic instead of waiting. The poll now counts comments from the answer and treats an answer with none listed as not there yet, so wait_until goes on waiting.

searching_code asserted shards() == 2 straight after the push to needle-two was found. Zoekt writes the new shard before it deletes the one it replaces, so the search could already see the push while three shards were on disk. That count, and the final found("needle_") == 2 after the deleted repository's shards go, now wait with wait_until.

Why

Both tests failed once and passed on their retry, logged FLAKY:. Each asserted a state that is only reached a moment later, rather than waiting for it with the existing helper.

How it was checked

cargo fmt and clippy on knotless-serve's tests here. The tests run on the runner.

Shortcomings

The poll takes no branch on the status, so coverage does not depend on whether the first poll saw the issue.

Changeset: none

🤖 Generated with Claude Code

Approved

This makes two flaky tests wait for their state instead of asserting it at once. In private_repositories_indexed_here the poll now calls looked directly, so a 404 gives None instead of tripping the 200 assertion. In searching_code the shard count and the final found("needle_") == 2 now go through wait_until. I read the diff and the looked and read helpers, and both changes look right and match the stated cause.

One small risk, not worth blocking on: the new poll does serde_json::from_str(&said).unwrap() on a response that may be a 404. That is fine if the appview's XRPC errors are always JSON, as they appear to be. If a 404 ever came back as plain text, the test would panic again instead of waiting. Using .ok() there would make the poll tolerant of that.

I did not read the checks. The tests run on the runner, and I did not wait for them.

Merged as f80d9ac