Adapter instances are not updated after configuration changes

[markoceri]

Description

Currently, the AdapterService maintains a cache of already-initialized adapter instances (e.g., Notifier, EnergyMonitor, MinerController, etc.). When the configuration of an adapter is updated (for example, changing the connection parameters of a Notifier or changing the ExternalService ID), the cache is not invalidated and the existing instance is returned, which uses the old configuration.

This behavior causes the use of outdated adapter instances, making any configuration change ineffective until the application is restarted (which clears the cache and forces the creation of new instances with the updated configuration).

How to reproduce

1. Start the application and ensure that an adapter (e.g., Notifier) has been initialized at least once.
2. Update the adapter's configuration (e.g., change token, endpoint, etc.).
3. Request the adapter instance again through AdapterService.
4. The returned instance will still use the old configuration.

Expected behavior

When an adapter's configuration is updated, the cache for that instance should be invalidated so that the next request returns a new, updated instance.

Possible solutions

• Implement a mechanism to invalidate the adapter cache when a configuration change is detected.
• Expose a public method to force the invalidation of a specific cached instance.
• Associate a hash/version of the configuration with the cache and recreate the instance if the configuration has changed.

Impact

Configuration changes to adapters have no effect until the application is restarted, potentially causing malfunctions and loss of operational flexibility.