[TST] bump hypothesis

[codetheweb]

Hypothesis has made many improvements in the last few months, including closing issues like https://github.com/HypothesisWorks/hypothesis/issues/3618.

Hoping that this will fix the recent error

Data generation is extremely slow: Only produced 9 valid examples in 225.14 seconds (0 invalid ones and 744 exceeded maximum size). Try decreasing size of the data you're generating (with e.g. max_size or max_leaves parameters).

(https://github.com/chroma-core/chroma/actions/runs/9505770742/job/26201473178)

or at least provide a better place to start debugging from.

(Seems like this error may have started occurring after https://github.com/chroma-core/chroma/pull/2297 was merged.)

Note: hypothesis was originally pegged in https://github.com/chroma-core/chroma/pull/1760.

[github-actions[bot]]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• [ ] Can you think of any use case in which the code does not behave as intended? Have they been tested?
• [ ] Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• [ ] If appropriate, are there adequate property based tests?
• [ ] If appropriate, are there adequate unit tests?
• [ ] Should any logging, debugging, tracing information be added or removed?
• [ ] Are error messages user-friendly?
• [ ] Have all documentation changes needed been made?
• [ ] Have all non-obvious changes been commented?

  System Compatibility

• [ ] Are there any potential impacts on other parts of the system or backward compatibility?
• [ ] Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

  Quality

• [ ] Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

[codetheweb]

Can we just manually verify that the tests are still going through the state machine?

Thanks for double checking. I did some investigation and commit 0c052da fixes this branch to have the expected behavior (without impacting correctness, to my knowledge). Currently:

• on main with the fast preset: all rules except delete_by_ids() are called (I'd consider this check to be currently broken in PRs)
• on main with the normal preset: all rules are called
• on this branch with the fastpreset: all rules are called
• on this branch with the normalpreset: all rules are called

(fast is used for PR checks, normalis used for releases)

going to open an issue on hypothesis to see if there's a way to assert rules are called a minimum number of times/if we can add that feature so this doesn't happen again

[codetheweb]

after these updates the state changes for both PersistEmbeddingsStateMachine and EmbeddingStateMachine lgtm