shutdown/close doesn't fully reset API state

[toddbaert]

The spec (requirement 1.6.2) says shutdown MUST reset all API state, removing hooks, event handlers, and providers. There's also a pending clarification to explicitly include evaluation context and transaction context propagators (open-feature/spec#375).

Right now, close() only shuts down providers but doesn't clear or reset them. clearProviders() resets providers to no-op but doesn't touch hooks, event handlers, evaluation context, or transaction context propagators. Neither function fully satisfies 1.6.2.

Found this while doing a cross-SDK audit for Python 1.0 readiness.

[Krishan27]

Hi @toddbaert, I’d like to work on this issue.

My understanding is that the shutdown path should reset all API-managed state, including:

• registered providers, including domain-scoped providers
• global and domain-scoped hooks
• registered event handlers
• global evaluation context
• the transaction-context propagator

I plan to start by adding tests that demonstrate the retained state after close(), and then implement a single internal reset path so provider shutdown and API-state cleanup remain consistent.

One question before implementation: should clearProviders() remain provider-only for backward compatibility, with the complete API reset performed by close()?

[toddbaert]

Hi @toddbaert, I’d like to work on this issue.

My understanding is that the shutdown path should reset all API-managed state, including:

• registered providers, including domain-scoped providers
• global and domain-scoped hooks
• registered event handlers
• global evaluation context
• the transaction-context propagator

I plan to start by adding tests that demonstrate the retained state after close(), and then implement a single internal reset path so provider shutdown and API-state cleanup remain consistent.

That sounds good.

One question before implementation: should clearProviders() remain provider-only for backward compatibility, with the complete API reset performed by close()?

Ya, I would keep this as is.

[Krishan27]

@toddbaert PR for this issue -> #1430