IOptionsMonitor always triggering OnChange

[Reintjuu]

Describe the bug

When using IOptionsMonitor in combination with this library, its OnChange always seems to trigger, even if there are no changes to the configuration.

1. I'm not sure, but I think it's related to the OnReload always being triggered (https://github.com/MrZoidberg/VaultSharp.Extensions.Configuration/blob/master/Source/VaultSharp.Extensions.Configuration/VaultConfigurationProvider.cs#L83).
2. I think it's also related to https://github.com/MrZoidberg/VaultSharp.Extensions.Configuration/blob/master/Source/VaultSharp.Extensions.Configuration/VaultConfigurationProvider.cs#L106. The logger is always logging that the key is outdated, even if it's just the "current" key. Shouldn't there be 3 states instead: new, current, outdated?

And I know it's not entirely related to this issue, but the README mentions that sometimes values don't reload and show old/empty values (dotnet/runtime#37860). I was not able to reproduce that issue. Could it be related to the RunAsync not being awaited and the configuration simply not being there yet (https://github.com/MrZoidberg/VaultSharp.Extensions.Configuration/blob/master/Source/VaultSharp.Extensions.Configuration/VaultConfigurationProvider.cs#L80)?

To Reproduce

I've reproduced the issue in this repo: https://github.com/Reintjuu/hashicorp-vault-dotnet-example.

Expected behaviour

OnChange should only trigger when there is an actual change to the configuration.

[MrZoidberg]

Thanks for the great issue description.

Indeed, OnReload() is always reloaded in the VaultChangeWatcher, so it should trigger OnChange() in IOptionsMonitor. I've fixed this in the upcoming release. Please note that it checks the version of data in Vault, not the actual values.

RunAsync should not be awaited, it has a Join method that blocks the calling thread.

I hope my fix resolves your issue. I'm planning to do a release asap.

[Reintjuu]

Thanks, it seems to work now!

Regarding my 2nd point, I think it's more of a semantic issue, it's always logging that the key is outdated because secretData.SecretData.Metadata.Version == currentVersion; is false for secretData.SecretData.Metadata.Version > currentVersion;. That's why I suggested implementing 3 states, instead of 2, for cases when a (current version) cached key is found.

I'll close the issue when your PR is merged.