"Error deserializing Salesforce CLI success response for input string <date>"

[Attila Hajdrik]

When doing a connection listing even I get this error as in the attached image, is it a known issue?

I’ll downgrade and probably will be unblocked, but wondering what is happening.

version: sfdx-cli/7.110.0 darwin-x64 node-v14.15.0

‌

ok, it seems that the root cause is that IC2 expects an epoch value, but now for new scratch orgs created is an ISO date…

‌

updating to blocker as it blocks any work

[Attila Hajdrik]

Tested a few CLI versions, it is not a client side date translation issue…. sfdx force:org:list returns the same ISO value in created and createdDate fields, that’s causing the issue I guess they fixed the inconsistency on the service side finally.

[Scott Wells]

Hi. I'm not seeing the issue. I'm on the latest build of IC2 (2.1.8.4) and the latest build of the CLI (7.110.0-85b006b) and IC2 is able to get an org list.

Can you please enable debug logging for Salesforce DX, reproduce the issue, and either attach or email the resulting idea.log that contains the output of force:org:list so that I can see what's going on?

[Scott Wells]

FYI, I also just went through the process of creating a new scratch org (force:org:create) after which IC2 re-listed the CLI connections (force:org:list) and loaded the details for the new connection (force:org:details), all without issue. How did you install the CLI? I wonder if it's possible that it's a difference between a binary-based install and an npm-based install. I'll check my test Mac and see whether it's reproducible there.

[Attila Hajdrik]

I am using npm based install, let me go ahead and enable logging, brb

[Scott Wells]

No issues on my Mac either, though it uses a binary-based install. I'll definitely need a log showing the JSON output to see what's changed exactly.

[Attila Hajdrik]

Tested with the binary, it is the same, which is ok.

[Scott Wells]

This is a CLI regression. As a result, I've filed the following bug:

https://github.com/forcedotcom/cli/issues/1091

At least until I hear back from the CLI team (and I'll also ping the members directly for expediency), for the moment I'd recommend that you roll back your CLI to a version that didn't have this breaking change. If it's going to take a while for them to fix, I'll issue a hotfix to IC2 on Monday, but hopefully they'll react quickly as I have to imagine that this is going to break any number of third-party integrations (other IDEs, CI/CD systems, etc.).

[Attila Hajdrik]

I went back a few CLI version down to 7.100.0 did not help, I can try to downgrade further to see it this will work.

[Scott Wells]

I'd recommend switching to the binary install given that I'm not seeing the issue on a Mac at the latest version installed that way.

[Scott Wells]

Just saw your "Tested with the binary" comment. Are you saying it has the same issue or that it's working properly? Sorry, just don't understand that comment...

[Attila Hajdrik]

It is the same issue, the “binary” is just a pkg based wrapper in a self contained install, no difference from the npm based one in terms of sources.

[Scott Wells]

Oh, there are absolutely differences. There have been numerous times that the npm install has been broken when the binary install has been fine. There seems to be some different packaging mechanism that can end up including different artifacts. It's possible they've addressed that recently, but as recently as a month or two ago the npm install was broken while the packaged installer was just fine.

However, if this is happening to you across all installs and versions, it makes me wonder if there's some environmental difference, e.g., something enabled in your dev hub that's not enabled in mine (or other users' since I've not heard about this from anyone else) that's actually changing the output. Anything like that come to mind?

[Scott Wells]

Here's a build with a prospective workaround ("prospective" since I can't reproduce the issue). Download the archive, but don't extract it. Install it using Settings / Preferences > Plugins > Install plugin from disk (under the gear drop-down menu).

Feel free to go back to the latest build of the CLI install via npm if you want since other builds/install methods aren't making a difference for you.

Please let me know whether that helps or not.

[Attila Hajdrik]

Thanks, I’ll test it in a minute, meanwhile I debugged SFDX and check where is that information coming from.

force:org:list reads in the locally cached auth json files from ~/.sfdx which has the ‘created’ field as an ISO, so when that file was created during org creation an ISO date was written there, after hand edited back to an epoch value everything worked with the released IC2.

To reproduce, open $HOME/.sfdx/[e-mail] and put an ISO date to the created property and then you can observe the issue I was facing.

Luckily I am unblocked now either way, thanks for the hotfix as well!

[Scott Wells]

Evidently the fix for this has now been pushed to the CLI RC channel which is where the problem existed. That's why other users weren't seeing it, I guess. Your local fix to the file to change the date format is a fine workaround, and then staying on the released build should help there as well.

Resolving this IC2 issue...

[Attila Hajdrik]

Out of curiosity, where do you see the fix has pushed? I probably checked the wrong SF repo?

[Scott Wells]

This is the link that was sent to me:

https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md

[Attila Hajdrik]

Ah then the repo is correct, they just not developing it in the open Thanks!