[luantaraschi]

💡 Motivation and Context

Local regex and not_regex matching turns the property into a string with str(), so non-string properties are matched against their Python repr: True, [1, 2], {'a': 1}. The flags service keeps strings as they are and serializes everything else as compact JSON (to_string_representation in rust/feature-flags/src/properties/property_matching.rs), which gives true, [1,2] and {"a":1}. So a condition like regex "^true$" on a boolean property is false when evaluated locally and true on the server. The local evaluator spec in PostHog/sdk-specs states the same rule, and the [1,2] row of its regex outline fails on main.

The other text operators (icontains, starts_with, ends_with) already use _value_to_string. This makes regex and not_regex use it as well.

One behavior change: a date or datetime property used with regex used to be matched against str(value). It now raises InconclusiveMatchError and falls back to remote evaluation, which is what icontains and starts_with already do for those types. Floats come out the same as before (1.0, 1e+20).

💚 How did you test it?

• New test_regex_stringifies_non_string_properties_as_compact_json covers a list, a bool and an object, each with regex and not_regex, plus two rows checking that the Python spellings (True, 'a') no longer match. All five cases fail on main and pass with the fix. The 353 tests in test_feature_flags.py pass.
• ruff format --check, ruff check (0.12.2), the mypy baseline and python -W error -c "import posthog" are clean.
• Full suite in a python:3.12-slim container: 5850 passed on main, 5855 passed with this change, no failures in either.

📝 Checklist

• All commits are signed (see Commit signing)
• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Claude Code with Claude Opus 5.5 found this while checking posthog-python against the server scenarios in PostHog/sdk-specs, reproduced it against a local mock server, and wrote the fix and the tests. Luan directed the work.