feat: improve contextEnrichment to handle special cases. (#229)

Signed-off-by: Simon Schrottner <simon.schrottner@dynatrace.com>
open-feature · Feb 20, 2025 · fe7aecb · fe7aecb
1 parent 1ddd993
commit fe7aecb
Show file tree

Hide file tree

Showing 2 changed files with 50 additions and 17 deletions.
diff --git a/gherkin/contextEnrichment.feature b/gherkin/contextEnrichment.feature
@@ -0,0 +1,50 @@
+@contextEnrichment
+Feature: Context Enrichment
+
+  Background:
+    Given a stable flagd provider
+
+  @in-process @rpc
+  Scenario: Use enriched context
+    Given a String-flag with key "flagd-context-aware" and a default value "not"
+    When the flag was evaluated with details
+    Then the resolved details value should be "INTERNAL"
+
+  @grace @in-process
+  Scenario: Use enriched context on connection error for IN-PROCESS
+    Given a String-flag with key "flagd-context-aware" and a default value "not"
+    And a stale event handler
+    And a ready event handler
+    When the flag was evaluated with details
+    Then the resolved details value should be "INTERNAL"
+    When the connection is lost for 6s
+    And a stale event was fired
+    When the flag was evaluated with details
+    Then the resolved details value should be "INTERNAL"
+    When a ready event was fired
+
+  @grace @rpc
+  Scenario: Use enriched context on connection error for RPC
+    Given a String-flag with key "flagd-context-aware" and a default value "not"
+    And a stale event handler
+    And a ready event handler
+    When the flag was evaluated with details
+    Then the resolved details value should be "INTERNAL"
+    When the connection is lost for 6s
+    And a stale event was fired
+    When the flag was evaluated with details
+    Then the resolved details value should be "not"
+    When a ready event was fired
+
+  @rpc @caching
+  Scenario: Use enriched context on RPC connection will not cache the value
+    Given a String-flag with key "flagd-context-aware" and a default value "not"
+    And a change event handler
+    And a ready event handler
+    When the flag was modified
+    And a change event was fired
+    And the flag was evaluated with details
+    Then the reason should be "TARGETING_MATCH"
+    # ensure that we do not cache a "TARGETING_MATCH", we should only cache evaluation with a "STATIC" reason
+    When the flag was evaluated with details
+    Then the reason should be "TARGETING_MATCH"
diff --git a/gherkin/targeting.feature b/gherkin/targeting.feature
@@ -144,20 +144,3 @@ Feature: Targeting rules
       | missing-variant-targeting-flag    | 3     |
       | non-string-variant-targeting-flag | 2     |
       | empty-targeting-flag              | 1     |
-
-  @contextEnrichment
-  Scenario: Use enriched context
-    Given a String-flag with key "flagd-context-aware" and a default value "not"
-    When the flag was evaluated with details
-    Then the resolved details value should be "INTERNAL"
-
-  @contextEnrichment @grace
-  Scenario: Use enriched context on connection error
-    Given a String-flag with key "flagd-context-aware" and a default value "not"
-    And a stale event handler
-    When the flag was evaluated with details
-    Then the resolved details value should be "INTERNAL"
-    When the connection is lost for 6s
-    And a stale event was fired
-    When the flag was evaluated with details
-    Then the resolved details value should be "INTERNAL"