Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Reentrant provider events reach client callbacks out of order

Cerrado
  • ¿Algo no está bien?
#332 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
ruby
Área
backend

Línea de trabajo

Start with dispatch_provider_event in lib/open_feature/sdk/configuration.rb, where global handlers run before client handlers and can re-dispatch reentrantly. Run the reproduction from the issue both ways (default and ready_stale) to confirm the wrong order. Done means both commands print the expected order, and deferred events keep their emission order and are dropped when a provider is shut down or replaced. The author says a local fix is already in preparation, so check with them before starting.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

Applications tracking provider availability through client event handlers can receive PROVIDER_READY followed by PROVIDER_ERROR after a provider has recovered. A similar sequence delivers PROVIDER_STALE before the preceding PROVIDER_READY.

This happens when a global event handler synchronously emits another provider event. The nested event reaches client handlers before the original event does. It reproduces with openfeature-sdk 0.5.1, 0.6.5, and current main at e602d1559af71324dcc11cc45462ba47075f32f9, using Ruby 4.0.1.

Related: #300 tracks provider lifecycle event ownership, and #137 tracks broader concurrency. This reproduction uses an already initialized provider and manually emitted events, so it also occurs independently of synthetic initialization events.

Reproduction

Save this as repro.rb and run it in an environment with openfeature-sdk installed. No Datadog dependency, network requests, or background threads are needed.

require "open_feature/sdk"

class EmittingProvider < OpenFeature::SDK::Provider::InMemoryProvider
  include OpenFeature::SDK::Provider::EventEmitter
end

configuration = OpenFeature::SDK.configuration
provider = EmittingProvider.new
configuration.set_provider_and_wait(provider)
provider.emit_event(OpenFeature::SDK::ProviderEvent::PROVIDER_STALE)
client = OpenFeature::SDK::Client.new(provider: provider)
events = []

first, following = (ARGV.first == "ready_stale") ? [:READY, :STALE] : [:ERROR, :READY]
first_event = OpenFeature::SDK::ProviderEvent.const_get("PROVIDER_#{first}")
following_event = OpenFeature::SDK::ProviderEvent.const_get("PROVIDER_#{following}")
configuration.add_handler(first_event, ->(_) { provider.emit_event(following_event) })
client.add_handler(first_event, ->(_) { events << first })
client.add_handler(following_event, ->(_) { events << following })
events.clear # Ignore immediate callbacks during handler registration.

provider.emit_event(first_event)
puts "Expected: #{[first, following].inspect}; actual: #{events.inspect}"
Command Expected callbacks Actual callbacks
ruby repro.rb [:ERROR, :READY] [:READY, :ERROR]
ruby repro.rb ready_stale [:READY, :STALE] [:STALE, :READY]

Proposed direction

In Configuration#dispatch_provider_event, state is updated before global handlers and then client handlers run. A global handler can recursively dispatch another event before the original client callbacks finish.

Finish delivery of the current event to global and client handlers before dispatching events emitted reentrantly on the same thread. Deferred events should preserve their emission order and payload, and must be invalidated when the associated provider registration ends through shutdown or replacement. This need not impose total ordering across independent threads.

A local fix and SDK-native regression tests are in preparation. The downstream report that led to this reproduction is DataDog/dd-trace-rb#6418.

Lenguaje dominante
Ruby
Estrellas
43
Forks
18
Merge medio
3 h 1 min
PR fusionados (30 d)
38

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de open-feature/ruby-sdk

Todos los issues de open-feature/ruby-sdk

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.