feat: populate event details payload with error_code and message

[josecolella]

Summary

• ProviderStateRegistry now stores event details (error_code, message, flags_changed, etc.) alongside provider state, so immediate handlers attached after a provider enters ERROR state can access the full error context
• Configuration#run_immediate_handler now includes stored details via build_event_details helper — previously only sent {provider_name: ...}
• Adds 3 spec tests for Requirements 5.1.4 and 5.1.5, including a test that immediate handlers receive error details when attached after the error occurred

Closes #210

Spec References

• Requirement 5.1.4 — PROVIDER_ERROR events SHOULD populate error message
• Requirement 5.1.5 — PROVIDER_ERROR events SHOULD populate error code

This completes Phase 1 (all MUST/Stable requirements) of the spec compliance roadmap: #220

Test plan

• bundle exec rspec spec/specification/events_spec.rb — 14 examples, 0 failures
• bundle exec rspec — 351 examples, 0 failures
• bundle exec standardrb — no offenses

🤖 Jose's AI agent

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the OpenFeature SDK's event handling mechanism by ensuring that PROVIDER_ERROR events carry complete error context, such as error codes and messages. This enhancement allows immediate event handlers to access detailed information about provider failures, fulfilling key OpenFeature specification requirements and completing a crucial phase of the spec compliance roadmap.

Highlights

• Enhanced Event Detail Storage: The ProviderStateRegistry was enhanced to store comprehensive event details, including error codes and messages, alongside the provider's state, allowing for richer context in event handling.
• Improved Immediate Handler Context: The Configuration#run_immediate_handler method was updated to utilize a new build_event_details helper, ensuring that immediate event handlers receive the full context of provider events, not just the provider name.
• New Specification Compliance Tests: New specification tests were introduced to validate compliance with Requirements 5.1.4 and 5.1.5, specifically confirming that PROVIDER_ERROR events correctly populate error messages and codes, and that these details are accessible to immediate handlers even when attached post-error.

Changelog

• lib/open_feature/sdk/configuration.rb
  • Updated run_immediate_handler to use build_event_details for comprehensive event data.
  • Added a new private helper method build_event_details to construct event details by merging provider name with stored event details.
• lib/open_feature/sdk/provider_state_registry.rb
  • Modified set_initial_state to store provider state as a hash {state: state, details: {}} instead of just the state.
  • Updated update_state_from_event to store event details alongside the new state.
  • Modified get_state to retrieve only the state from the stored hash.
  • Added a new method get_details to retrieve the stored event details for a provider.
• spec/specification/events_spec.rb
  • Added a new test context for "Requirement 5.1.4" to verify PROVIDER_ERROR events populate the error message field.
  • Added a new test context for "Requirement 5.1.5" to verify PROVIDER_ERROR events populate the error code field.
  • Added a test within "Requirement 5.1.5" to confirm error details are available to immediate handlers attached after an error has occurred.

Activity

• The ProviderStateRegistry was modified to store event details alongside provider state.
• The Configuration#run_immediate_handler was updated to include these new event details.
• Three new specification tests were added to validate the correct population of error codes and messages in PROVIDER_ERROR events, and to ensure immediate handlers can access these details.
• All existing tests (bundle exec rspec) passed with 0 failures.
• Code style checks (bundle exec standardrb) reported no offenses.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request effectively adds support for populating event details in PROVIDER_ERROR events, ensuring that handlers can access error context even when attached after the fact. The implementation is solid, and the new tests provide good coverage for the specified requirements. I have a couple of suggestions to enhance test reliability and improve code conciseness.

[gemini-code-assist]

Using a fixed-duration sleep for synchronizing with asynchronous operations can lead to flaky tests, especially in slower CI/CD environments. A more robust approach is to poll until the desired state is reached.

      sleep(0.001) until OpenFeature::SDK.configuration.provider_state(provider) == OpenFeature::SDK::ProviderState::ERROR