ConnectedOrgVersion stays 9.0.0.0 for ExternalTokenManagement connections #538

Summary

When Microsoft.PowerPlatform.Dataverse.Client.ServiceClient is constructed via the token-provider / AuthenticationType.ExternalTokenManagement path, ConnectedOrgVersion can remain stuck at 9.0.0.0 instead of reflecting the actual connected Dataverse organization's version.

I specifically verified this with the custom-token / external-auth path because that is the scenario I am using.

Repro

1. Construct a ServiceClient using the ExternalTokenManagement / custom token acquisition path (for example via an access-token provider callback used for custom OAuth, device code, WIF, etc.).
2. Connect to any current Dataverse online environment.
3. Read ServiceClient.ConnectedOrgVersion immediately after the client is established.

Expected behavior

ConnectedOrgVersion should reflect the real connected organization's version.

Actual behavior

ConnectedOrgVersion returns 9.0.0.0.

Context

This was confirmed against a real current Dataverse online environment using the installed SDK package 1.2.10 binary.

• ConnectedOrgVersion initially reported 9.0.0.0.
• The actual environment version was 9.2.26061.150.
• Accessing the public ServiceClient.OrganizationDetail property correctly populated and returned the real org version.
• Executing RetrieveVersionRequest also returned the correct real version.

That suggests the connection/auth/transport are otherwise fine, and that this specific initialization path is leaving the cached org version stale.

Using the closest available public source tag I could find (1.2.9), the general area of the ExternalTokenManagement login path in ConnectionService.cs appears to:

• set OrganizationVersion to 9.0.0.0, and
• skip the normal server-version discovery calls (GetServerVersion / RefreshInstanceDetails) in that path.

ServiceClient.ConnectedOrgVersion in ServiceClient.cs then appears to simply return the cached value.

Impact

This can cause callers to make incorrect feature-gating decisions based on a false low org version.

A concrete public example: https://github.com/TALXIS/tools-cli consumes this constructor path for modern token-based execution of Configuration Migration Tool / Package Deployer-style workflows, and has to account for this behavior because CMT-style import logic enables UpsertMultiple batch mode only when ConnectedOrgVersion >= 9.2.23083.00120.

If ConnectedOrgVersion incorrectly stays at 9.0.0.0, that logic falls back to much slower one-by-one operations even though the connected environment actually supports the newer capability.

Proposed fix

Either of these would resolve the issue:

1. In this connect/login path, call the same real version discovery logic (RefreshInstanceDetails / GetServerVersion) once the connection is established.
2. Or, make ConnectedOrgVersion lazily trigger a real lookup when it still holds the uninitialized/default 9.0.0.0 value, instead of returning that stale value indefinitely.

Happy to validate a fix if useful.