feat(feature-flags): support early_exit in local evaluation

[gustavohstrassburger]

💡 Motivation and Context

PostHog added an "early exit" option to feature flags in the server-side (Rust) evaluation engine, and it has already been ported to posthog-node and posthog-python. This PR ports the same behavior to the Ruby SDK's local evaluation.

When a flag's filters.early_exit is true, local condition evaluation must STOP and return a definitive disabled result as soon as a condition group's property filters match (or the group has no property filters) but the rollout percentage EXCLUDES the user — instead of falling through to evaluate later condition groups.

To mirror the Rust engine exactly, the single-group matcher now returns a tri-state outcome instead of a boolean:

• :match — property filters matched AND rollout included the user (existing behavior).
• :no_match — a property filter did NOT match -> always falls through to the next group, even with early_exit enabled.
• :out_of_rollout_bound — property filters matched (or there were none) but the rollout percentage excluded the user. With early_exit enabled, the loop returns a definitive disabled result immediately; otherwise existing fall-through behavior is preserved.

early_exit is read from the flag's filters and defaults to false/absent, so behavior is unchanged for existing flags.

💚 How did you test it?

• Added unit tests against match_feature_flag_properties covering: (a) early_exit enabled returns false without evaluating a later group that would match; (b) early_exit unset falls through to the later matching group (returns true); (c) early_exit explicitly false falls through (returns true); (d) a group failing on a property filter (not rollout) does NOT early-exit even when enabled and falls through to a later matching group. The first group uses matching properties with rollout_percentage: 0 and the second uses matching properties with rollout_percentage: 100.
• Existing condition_match tests still pass via a thin boolean wrapper over the new tri-state method.
• Ran the full suite: bundle exec rspec -> 446 examples, 0 failures.
• Ran the linter/formatter: bundle exec rubocop -> no offenses on changed files.

📝 Checklist

• 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 pnpm changeset to generate a changeset file

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
spec/posthog/flags_spec.rb:1671-1693
Three of the new tests are structurally identical — they all call `build_flag` with a different `early_exit` value and assert on the result. The repo's stated convention is to always prefer parameterised tests; these three contexts fit that pattern exactly and could be collapsed into a single table-driven loop.

```suggestion
    [
      [true,  false, 'enabled'],
      [nil,   true,  'unset'],
      [false, true,  'explicitly false']
    ].each do |early_exit_val, expected, description|
      context "when early_exit is #{description}" do
        it "returns #{expected}" do
          flag = build_flag(early_exit: early_exit_val)
          result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
          expect(result).to be expected
        end
      end
    end
```

_{Reviews (1): Last reviewed commit: "chore(feature-flags): trim redundant com..." | Re-trigger Greptile}

[greptile-apps]

Three of the new tests are structurally identical — they all call build_flag with a different early_exit value and assert on the result. The repo's stated convention is to always prefer parameterised tests; these three contexts fit that pattern exactly and could be collapsed into a single table-driven loop.

Suggested change

	context 'when early_exit is enabled' do
	it 'returns false without evaluating a later matching group' do
	flag = build_flag(early_exit: true)
	result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
	expect(result).to be false
	end
	end
	context 'when early_exit is unset' do
	it 'falls through to the later matching group and returns true' do
	flag = build_flag(early_exit: nil)
	result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
	expect(result).to be true
	end
	end
	context 'when early_exit is explicitly false' do
	it 'falls through to the later matching group and returns true' do
	flag = build_flag(early_exit: false)
	result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
	expect(result).to be true
	end
	end
	[
	[true, false, 'enabled'],
	[nil, true, 'unset'],
	[false, true, 'explicitly false']
	].each do |early_exit_val, expected, description|
	context "when early_exit is #{description}" do
	it "returns #{expected}" do
	flag = build_flag(early_exit: early_exit_val)
	result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
	expect(result).to be expected
	end
	end
	end

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: spec/posthog/flags_spec.rb
Line: 1671-1693

Comment:
Three of the new tests are structurally identical — they all call `build_flag` with a different `early_exit` value and assert on the result. The repo's stated convention is to always prefer parameterised tests; these three contexts fit that pattern exactly and could be collapsed into a single table-driven loop.

```suggestion
    [
      [true,  false, 'enabled'],
      [nil,   true,  'unset'],
      [false, true,  'explicitly false']
    ].each do |early_exit_val, expected, description|
      context "when early_exit is #{description}" do
        it "returns #{expected}" do
          flag = build_flag(early_exit: early_exit_val)
          result = poller.send(:match_feature_flag_properties, flag, distinct_id, properties, evaluation_cache)
          expect(result).to be expected
        end
      end
    end
```

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[dustinbyrne]

greptile loves parameterization but this looks good