Subscription Config Default Change Not Replicated to Exchange Config

[shazbert]

There is an issue with how subscription configurations are handled when the default settings are modified on exchange upgrades. If the default configuration is changed, the update is not properly replicated to the exchange config. This leads to two potential problems:

• The expand template fails due to inconsistencies between the updated default and the exchange config.
• Subscribing to WebSocket channels results in unexpected behaviour or inconsistencies because the subscription state does not reflect the new default settings.

To resolve this, we need a mechanism to either:

1. Automatically refresh the config to ensure the exchange config stays in sync with the updated default, or
2. Provide a clear warning to users when there are discrepancies between the current state and the expected config, prompting them to purge and rebuild the entire subscription list.

[gloriousCode]

Perhaps a config upgrade along with the PR that changes it, which would transition a subscription from say accounterinos into accounteroos (or account to myAccount as per Coinbase PR) rather than 1, which sounds like it would overwrite all the customisation that can occur for config subscriptions (eg enabled status, assets and intervals)
Config upgrades occur before everything else starts.

We can see a close enough example to this with v2.go, where it targets a specific exchange and updates the json.

Main downside is that it requires the PR-person changing the subscription to know to add a config version. Sure an automated system would be nice, but I don't think requiring the change as a review policy is too bad

[gloriousCode]

I should add one more thing. A temporary solution for this is to delete all subscriptions in your config for the exchange affected, the updated/changed subscriptions will be added on next startup

[gbjk]

I've struggled with this a few times, and I think it depends on context of the change.
For some changes it's "The old defaults are now wrong, and the user's subs need updating", and that probably means finding if they had the old default unchanged (or with the broken params in tact) and updating it.
e.g. orderbook 100ms is no longer available. Update to 200ms, but if the user had changed anything else, keep those changes.
Other changes are as simple as "This is now enabled by default" and can just be added.

For now, the best solution we have is that we use config versioning with case-by-case decisions about "what's the right thing to do".
We might end up refactoring a toolset for versions to manage subs faster.

There's an example of that here and I'll PR it shortly.

[thrasher-]

I've struggled with this a few times, and I think it depends on context of the change. For some changes it's "The old defaults are now wrong, and the user's subs need updating", and that probably means finding if they had the old default unchanged (or with the broken params in tact) and updating it. e.g. orderbook 100ms is no longer available. Update to 200ms, but if the user had changed anything else, keep those changes. Other changes are as simple as "This is now enabled by default" and can just be added.

For now, the best solution we have is that we use config versioning with case-by-case decisions about "what's the right thing to do". We might end up refactoring a toolset for versions to manage subs faster.

There's an example of that here and I'll PR it shortly.

Agree with this, though in the case where a user has made customisations. We can still validate against what the exchange's latest supported values are when performing upgrades to report to the user what's valid vs what's not and report an error if needed.

User upgrades should be seamless and a nice experience, requiring manual deletion or tampering to get the correct values is certainly not ideal and we should strive to avoid this at all costs.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Please provide an update or this issue will be automatically closed in 7 days.