fix(dotnet): support numeric equality and inequality in PolicyRule.EvaluateAtomic#3236
Open
DhineshPonnarasan wants to merge 2 commits into
Open
Conversation
…aluateAtomic PolicyRule.EvaluateAtomic previously only matched quoted string literals in the equality and inequality branches, so numeric forms like count == 5, count != 6, score == 3.14, and temperature == -5 always fell through to false even when the value matched. Add two sibling regex patterns (NumericEqualityPattern and NumericInequalityPattern) using the same (-?\d+(?:\.\d+)?) numeric shape as the existing ordered-comparison branch, and two corresponding evaluation branches placed between the string inequality and the ordered numeric branches in EvaluateAtomic. The new branches reuse ResolveField and the same double.TryParse path already used by NumericComparisonPattern so they parse identically. Closes microsoft#3205 Signed-off-by: Dhinesh Ponnarasan <dhineshponnarasan@gmail.com>
🤖 AI Agent: breaking-change-detector — API Compatibility
API Compatibility
|
🤖 AI Agent: code-reviewer — View details
TL;DR: 0 blockers, 1 warning. The PR improves numeric equality and inequality handling in
Action items:
Warnings:
|
🤖 AI Agent: test-generator — View details
Test coverage looks good. No gaps identified. |
🤖 AI Agent: docs-sync-checker — Docs Sync
Docs Sync
|
🤖 AI Agent: security-scanner — View details
No security issues found. |
PR Review Summary
Verdict: AI review comments are untrusted advisory output. The summary reports workflow-generated completion status only, not model-authored pass/fail claims. |
|
🟡 Contributor Check: MEDIUM
Automated check by AGT Contributor Check. |
github-actions
Bot
added
the
needs-review:MEDIUM
liamcrumm
approved these changes
Jul 1, 2026
liamcrumm
approved these changes
Jul 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves #3205.
The .NET PolicyRule.EvaluateAtomic previously required the right-hand side of
==/!=to be a quoted string literal, so numeric forms such ascount == 5,count != 6,score == 3.14, andtemperature == -5always fell through tofalseeven when the value matched. Only the ordered comparisons (>,>=,<,<=) accepted numeric literals.Approach
Two new sibling regex patterns (
NumericEqualityPatternandNumericInequalityPattern) and two matching evaluation branches inEvaluateAtomic, placed between the string-inequality branch and the ordered-numeric branch so the existing operator precedence reads cleanly.The new branches:
ResolveField(so dot-notation keeps working throughResolveField's nested-walk + flat-fallback behaviour)double.TryParseoverload already used byNumericComparisonPattern, so they parse identically and inherit the same culture conventions as the existing branchRegex shape is
-?\d+(?:\.\d+)?— matches the existing ordered-comparison branch's fragment and adds an optional leading sign for negative literals (required by the issue's positive-case matrix).Scope discipline
BooleanEqualityPattern(field == true|false, supported by the TypeScript SDK) is deliberately not added in this PR. Same operator surface as the existingBooleanFieldPatterntruthy check; will file a follow-up.agent-governance-python/agent-mesh/src/agentmesh/governance/policy.py(and the near-duplicate infederation.py). Out of scope for this .NET-only PR; will file follow-up parity issues.NumericComparisonPatternbranch's culture-parsing behaviour is unchanged. All three numeric branches now parse identically, which is what the issue explicitly required (consistency with existing numeric comparison operators).Tests
14 new
[Fact]methods inPolicyRuleTests.cs, mirroring the existing naming convention (Evaluate_<Concern>_<Scenario>):"five")count == 5 and risk < 0.5;count != 5 or count == 5data.count == 5count >= 'high') still cleanly returns false without throwingAll 14 new tests pass. All 778 pre-existing tests in the
AgentGovernancesolution remain green (792/792 total).Hi @imran-siddique, Could you please review this whenever you have some time, I'd really appreciate your feedback.
Thanks in advance!