Connection API version vs Metadata version

[Xander Victory]

Just ran into an issue where Flow Metadata was retrieved using an older API version and thus didn’t include elements needed (i.e. it couldn't redeploy the unmodified file).
Turns out sfdx-project.json had an older version listed (47.0) - logs indicate sfdx force:source:retrieve was being used.

Is the connection config supposed to affect the API version retrieved? or is this intended?

Even if there was just a warning on project open that the project json version didn't match the connection settings would be good.
I only found this because I retrieved the Flow using Workbench and tried to deploy that file, which gave an error mentioning API versions.

Project particulars:

• SFDX format project
• sfdx-project.json had
• Regular Sandbox connection (OAuth)
• IC2 settings lists API Version 56.0 for the connection
• Package.xml listed version 51 (seems irrelevant)

‌

[Scott Wells]

Since this is for a source format project with an sfdx-project.json, the connection API version for the project is derived from that file. However, that’s not necessarily the API version used when communicating with Salesforce. Any direct API connection made from IC2 to Salesforce--SOAP or REST--uses the latest API version as that’s how the Salesforce client used by IC2 works. Of course, if IC2 has to use the Salesforce CLI for something, e.g., deployment or retrieval via force:source:push/pull/deploy/retrieve, the CLI will use whatever API endpoint it’s using, though it should also be using the API version number from sfdx-project.json as appropriate when an explicit API version can be specified.

The API version number listed for a connection in the connection list for a CLI-managed connection in the absence of project context is always going to be the latest API version number because, again, the actual API version number is derived from the using project’s sfdx-project.json file.

If the project is not for a source-tracked organization, a package.xml file is used for deployments and retrievals, and that project’s registered package.xml file (via the metadata subscription) is used as a template for all of those operations performed directly via the Metadata API. So it’s good to have the API version number in that file properly specified as well.

The other place where an API version number can come into play is in various meta.xml files, e.g., those for Apex classes and triggers. Of course, those can be quite different from the project’s API version number and even from each others' API version numbers as needed for backward-compatibility, though I would say it should be a best practice to keep those current unless there’s a good reason to lock specific files in on an earlier version.

So that’s how all of this comes into play. I could see a few potential changes to make this more clear:

1. Make it clear that the API version number for a CLI-managed connection without project context is not “real”.

2. Add a code inspection to check API version numbers across the board as follows:

   1. If the value in package.xml or a meta.xml file doesn’t match the one in sfdx-project.json, warn with a quick fix to use one or the other. Of course, it needs to be trivial to suppress/ignore this warning, particularly in meta.xml files.
   2. If the value in sfdx-project.json is older than the latest platform API version, warn the user with a quick fix to update to the latest. The user should also be able to suppress/disable this.

Thoughts?

[René Görgens]

I was also confused by this (cf. issue 2230). I think all potential changes have a lot of merit, not least the meta.xml inspection which isn’t directly related to this issue.

[Xander Victory]

Of course, if IC2 has to use the Salesforce CLI for something, e.g., deployment or retrieval via force:source:push/pull/deploy/retrieve, the CLI will use whatever API endpoint it’s using, though it should also be using the API version number from sfdx-project.json as appropriate when an explicit API version can be specified

Yeah, that was seemingly the crux of the issue - despite the fact that the file’s API version was 56, the retrieve endpoint was giving ‘bad’ data (though WSDL level valid), and the deploy endpoint was rejecting the XML content when I did obtain a complete file.
I don’t recall what the file’s API version ended up being on the v47 retrieve.

Make it clear that the API version number for a CLI-managed connection without project context is not “real”.

Sounds good

If the value in package.xml or a meta.xml file doesn’t match the one in sfdx-project.json, warn with a quick fix to use one or the other. Of course, it needs to be trivial to suppress/ignore this warning, particularly in meta.xml files.

File/component level versions could be a weak warning unless the file’s version is greater than the project level one - I reckon that should be an error (on the meta file, not project level), at least in the XML files (and given a Flow is 100% metadata very important there).
Less important for something like an Apex class/trigger where the compiler isn't missing out on any info at this stage. In my experience Apex files get left on whatever version they were created on

If the value in sfdx-project.json is older than the latest platform API version, warn the user with a quick fix to update to the latest. The user should also be able to suppress/disable this.

I would find this useful - even if it just happened on OST refresh, though I would hope that info would be available somewhere from the CLI as it stores it in ~/.sfdx/<username>.json

[Katherine Idárraga]

I run into a similar issue when I refreshed my sandbox (which went to version 56) and the sfdx CLI (latest version) tried to connect using version 57 resulting in the following error.

‌

I was able to execute the command using the -a directly with the sfdx CLI successfully

‌

Perhaps you could use the API version specified in the project dialog and use the -a parameter to specify the api version when executing the sfdx command?

Thank you,

Kat

‌

[Katherine Idárraga]

I found the source of the issue, I setup the connection through Illuminated cloud and the configuration that the sfdx created used version 57 instead of 56

[Scott Wells]

New Inconsistent API version code inspection delivered in 2.2.5.9.