Design Question: Handle provider registration on SQL Workbench services

[cheenamalhotra]

As of current design, SQL workbench services can be registered with provider ID any number of times by provider itself or extensions, and the implementation would allow overriding provider reference without any restrictions.
e.g.

Account Management Service

azuredatastudio/src/sql/workbench/services/accountManagement/browser/accountManagementService.ts

Lines 418 to 423 in a38e8a7

	private async _registerProvider(providerMetadata: azdata.AccountProviderMetadata, provider: azdata.AccountProvider): Promise<void> {
	this._providers[providerMetadata.id] = {
	metadata: providerMetadata,
	provider: provider,
	accounts: []
	};

Object Explorer Service

azuredatastudio/src/sql/workbench/services/objectExplorer/browser/objectExplorerService.ts

Lines 578 to 580 in a38e8a7

	public registerProvider(providerId: string, provider: azdata.ObjectExplorerProvider): void {
	this._providers[providerId] = provider;
	}

and so on..

This design has been questioned multiple times while implementing same way in Error Diagnostics Service: #21627 (comment), #21627 (comment)

Questions for extensibility:

• Should provider registration be limited to per provider ID only once or should we allow multiple provider registrations with same ID?
• If once, what is the sequence of provider registration? How can we ensure the 'trusted' extensions get to register the services, and not others?

Since this design problem is applicable to multiple services, opening this issue for discussion, so it can be addressed universally.

cc @Charles-Gagnon @alanrenmsft

[alanrenmsft]

@cheenamalhotra for top level/main provider: connection provider, it has to be unique, no questions here. For other providers that works with the connection providers, the multi-provider approach gives us more flexibility, we can have providers in different extensions to handle different scenarios, but the downside is also obvious: the logic is separated out, there could be conflicts between different providers and their execution order is not predictable. Based on this, I like the single provider approach better.

[Charles-Gagnon]

It really depends on the use case, right? There are definitely scenarios where having multiple providers registered could be useful.

For example - with the error handling. What if a user wanted to create an extension that added further support for checking and handling errors from SQL connections? Especially with different flavors of engines - you may have the same base provider (MSSQL) but then have different error codes for specific types of installs.

Anyways that's just a "what if" scenario. I don't think there's any reason for us to support more than 1 provider for any of our current providers with the functionality we currently have (although the error handler stuff is definitely where I could see that being a request in the future). I just want to avoid having a blanket "we'll only ever need to support 1 provider ever" and rather encourage people to think about how they want their feature to be used and make sure they handle all cases appropriately.

[alanrenmsft]

definitely, I totally understand the potential benefits of allowing multiple providers, but I would prefer to choose the approach that is less error prone. so let's keep the single provider design until we have an actual use case.

@cheenamalhotra feel free to close the issue if this answers your question.