chore(flagpole-wildcard-op): Implementing 'matches' as a flagpole con…

[Abdkhan14]

NOTES:

• In par with sentry-options: chore(flagpole-wildcard-op): Implementing 'matches' as a flagpole condition sentry-options#124
• Task documentation: link

Adds a new matches condition operator that accepts a list of glob patterns and returns true if the context property value matches any of them. Patterns support * as a wildcard (zero or more characters); all other characters are treated literally.

Changes:

src/flagpole/conditions.py — adds MATCHES to ConditionOperatorKind, _glob_star_match helper (hand-rolled split-and-scan, no new dependencies), MatchesCondition class, and registers it in OPERATOR_LOOKUP.

src/flagpole/flagpole-schema.json — adds MatchesCondition definition and registers it in the Segment.conditions discriminator and oneOf.

tests/flagpole/test_conditions.py — adds TestMatchesConditions covering: literal match, prefix wildcard (jayonb*), prefix+suffix wildcard (jay.goss+onboarding*@sentry.io), suffix wildcard (@sentry.io), multi-star wildcard (ab*c), star-only pattern, case insensitivity, no-match, multiple patterns in one condition, and type mismatch errors for list/dict context properties.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 57aa280. Configure here.}

[wedamija]

Any reason we don't use glob_match instead of this custom function?

[markstory]

Longer term, we need the same behavior in both the current python implementation (this change), and in sentry-options. Using a more fully feature glob implementation is ok if we can have the same behavior across the python/rust implementations.

[wedamija]

glob_match implemented in rust in sentry-relay, so possibly there's a way we can share this logic between both systems at some point

[Abdkhan14]

Agree — longer term there's a path to aligning with relay's glob implementation if it ever becomes a shared crate. For now, moving forward with this hand-rolled star-only impl since it's easy to verify for cross-language parity and covers our use case.

[markstory]

That could work well. I'm hoping to not have the python implementation by the end of this year.

[markstory]

Looks good to me. I cross-checked against the Rust implementation.

[markstory]

Longer term, we need the same behavior in both the current python implementation (this change), and in sentry-options. Using a more fully feature glob implementation is ok if we can have the same behavior across the python/rust implementations.