Azure
Hot-Reload dependencies with an enforced order of operations
Why make this change?
Relates to https://github.com/Azure/data-api-builder/issues/67 Relates to https://github.com/Azure/data-api-builder/issues/2323 Relates to https://github.com/Azure/data-api-builder/issues/1869
This change adds event handling for the dependencies which are set during startup, and refreshing their internal state to match the states that are updated during a hot-reload. In order to help facilitate the final portions of the configuration file which need to be handled in hot-reload scenarios, we need these dependencies to be updated without any stale values from before the hot-reload. And we enforce an order of this update to make sure that if B depends on A, that the refresh happens first with A, then with B.
What is this change?
There are a number of classes which are instantiated and registered with the Service Provider on startup using values that depend on the 'RuntimeConfig'. These are registered as singletons. Therefore, during a hot-reload scenario, we need to update those states because the 'RuntimeConfig' has changed, and the values that those objects were instantiated with are now potentially stale. To handle this updating, when one of these singleton services is constructed, we subscribe an update function with an Event Handler that is provided to the constructor. We also save internally any arguments provided to the constructor that were needed during construction so that they will be available and usable during the updating.
The RuntimeConfig Loader then sequentially sends notifications for all of these subscribed events to inform them of the hot-reload process. This happens in a single function with a single thread so that the order of operation is enforced, with the thread executing each update one at a time.
Note that we save the handler internally in some of the classes that we will be calling back to do configurations during hot-reload. Generally speaking, this happens in the factory classes when their re-configuration during hot-reload requires them to create other classes that will need to be re-confiured during a hot-reload. Those classes then need to have a handler provided to their constructor so that they can properly subscribe to hot-reload events.
How was this tested?
Manually verified the updating process.
Sample Request(s)
Any change to the config used on startup will demonstrate the hot-reload functionality added in this PR.
