toddbaert
commented
1 year ago Thanks for opening this issue @jakedoublev .
This is indeed something that needs to be addressed. There was a concensus that it could be deferred for a time, but with a focus shifting toward client providers and eventing, that time has likely come. I'd recommend you take a look at https://github.com/open-feature/ofep/pull/30 and leave some of your thoughts there.
In the upcoming days I will try to coordinate an effort here and consolidate the interested contributors. I'll keep you apprised.
jakedoublev
beeme1mr
Background
As it currently stands, it doesn't appear there is current support within the spec or providers for
shutdownorclosurefunctionality. Multiple flag vendors instruct within their documentation that feature flagging clients should be shut down upon closure of the application or other necessity within the implementation: LaunchDarkly client closing, Go Feature Flag deferred closing, Harness feature flags closing.There are several reasons that a closing of the flag provision could be necessary:
Some of these reasons are even potential security issues (i.e. user information could remain inside OpenFeature and a Provider after logout in some cases). It's probably not a large or frequent issue, but security risks usually start that way.
Other Considerations
Post-shutdown behavior
The natural follow-up question if shutdown is provided is "what comes next?" That's a great question, and some thought is required to make sure it's handled well.
For example, take the case that an OpenFeature client is instantiated via a Provider and utilized in an application. Some state changes in the application that triggers the need for a shutdown, and with a pseudocode
client.shutdown()available, the closing of the OpenFeature Client as well as the flag vendor downstream though the Provider is successful. Everything is now shut down.With the client now closed, how should calls for flag values be handled? Throwing errors on flag state calls makes sense, but it's not the entire picture.
After shutdown, how should re-instantiation be handled? The metadata and context are defined for OpenFeature at instantiation of the OpenFeature client, so should those be cleared out as well on shutdown? In other words, does it make the most sense to clear everything out of the OpenFeature Client upon shutdown and render it unusable, throwing an error on every method?
This seems strict, but requiring re-instantiation of OpenFeature with new metadata likely makes the most sense if the flag vendor it is abstracting is also needing to be re-instantiated. A shut down client should not be functional in any way.
Shutdown/closing mean different things across flagging tools
This is perhaps the never ending question OpenFeature must handle: how can shutdown behavior be handled in a universally acceptable way? If a flag vendor does not support shutdown or closing, how can the Provider do so nonetheless? These answers will need to be handled on a case by case Provider basis with the expected behavior defined by the consensus at the OpenFeature spec level.
Hook to shut down?
In exploration of this issue, I looked into a hook as a potential option, but as they are related to flag call lifecycles and not the lifecycle of either the OpenFeature Client or Provider connection, hooks are not a viable solution.
Suggested Implementation
I propose a
shutdownmethod on the OpenFeature Client that:closeif availableInactiveClientErrororShutdownClientErrorerrors if any methods are invoked post-shutdown (or another informative error name)The upside is an increase in robustness, durability, and flexibility, and the downside is not immediately clear. Perhaps a downside is a lack of universality in what "shutdown" means across the flag vendors, but that shouldn't mean OpenFeature's spec cannot define what "shutdown" means with some finality.
I would argue that this functionality is not bloat or a request to support an insignificant, random use-case but rather is one of the areas where the spec can mature. I'm sure there will be more areas like this identified as utilization of both feature flagging and OpenFeature specifically grows.