feat: Add hook-data concept for hooks. #273
Open
Conversation
This file contains 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
kinyoklion
commented
Sep 30, 2024
| @@ -31,7 +31,9 @@ Hooks can be configured to run globally (impacting all flag evaluations), per cl | |||
|
|
|||
| ### Definitions | |||
|
|
|||
| **Hook**: Application author/integrator-supplied logic that is called by the OpenFeature framework at a specific stage. **Stage**: An explicit portion of the flag evaluation lifecycle. e.g. `before` being "before the [resolution](../glossary.md#resolving-flag-values) is run. **Invocation**: A single call to evaluate a flag. `client.getBooleanValue(..)` is an invocation. **API**: The global API singleton. | |||
| **Hook**: Application author/integrator-supplied logic that is called by the OpenFeature framework at a specific stage. | |||
There was a problem hiding this comment.
These were all on one line, which seemed hard to read. So I put a blank line between them to get them on multiple lines.
kinyoklion
commented
Sep 30, 2024
| @@ -81,75 +83,154 @@ see: [dynamic-context paradigm](../glossary.md#dynamic-context-paradigm) | |||
|
|
|||
| > Condition: The provider `metadata` field in the `hook context` **MUST** be immutable. | |||
|
|
|||
| ### 4.3. Hook creation and parameters | |||
| ### 4.3. Hook data | |||
There was a problem hiding this comment.
I prefer not renumbering, but I did in this case as conceptually it makes sense to group all the parameter requirements together. I could move this to retain the existing numbering.
kinyoklion
commented
Sep 30, 2024
|
|
||
| > `Hook data` **MUST** must be created before the first `stage` invoked in a hook for a specific evaluation and propagated between each `stage` of the hook. | ||
|
|
||
| Example showing data between `before` and `after` stage for two different hooks. |
There was a problem hiding this comment.
I am not sure if the diagram is overkill, but a key concept is that data is not shared between hooks and not shared between evaluations.
Signed-off-by: Ryan Lamb <[email protected]>
kinyoklion
force-pushed
the
rlamb/hook-data
branch
from
c42ef76
to
d391718
Compare
Signed-off-by: Ryan Lamb <[email protected]>
kinyoklion
force-pushed
the
rlamb/hook-data
branch
from
cb5cabb
to
2110b92
Compare
beeme1mr
reviewed
Sep 30, 2024
Co-authored-by: Michael Beemer <[email protected]> Signed-off-by: Ryan Lamb <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR
Add support for the hook-data concept for hooks. Hook-data allows for per-evaluation data to be propagated between hooks.
This is especially useful for analytics purposes where you may want to measure things that happen between stages, or you want to do something like create a span in one stage and close it in another.
This concept is similar to the
series dataconcept for LaunchDarkly hooks. https://github.com/launchdarkly/open-sdk-specs/tree/main/specs/HOOK-hooks#evaluationseriesdataUnlike
series datathe data in this approach is mutable. This is because thebeforestage already has a return value. We could workaround this by specifying a return structure, but it maybe seems more complex. The data is only passed to a specific hook instance, so mutability is not of great concern.Some functional languages may still need to use an immutable with return values approach.
I can create an OFEP if we think this merits discussion prior to proposal.
Related Issues
Related discussion in a PR comment.
open-feature/java-sdk#1049 (comment)