- edited description
"Error deserializing Salesforce CLI success response for input string <date>"
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
Comments (22)
-
reporter -
reporter - edited description
-
reporter - marked as blocker
- edited description
-
reporter 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.
-
repo owner 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 offorce:org:list
so that I can see what's going on? -
repo owner 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. -
reporter I am using npm based install, let me go ahead and enable logging, brb
-
repo owner 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.
-
reporter Tested with the binary, it is the same, which is ok.
-
repo owner 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.).
-
reporter 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.
-
repo owner 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.
-
repo owner 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...
-
reporter 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.
-
repo owner 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?
-
repo owner - attached IlluminatedCloud2.zip
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.
-
repo owner - changed title to "Error deserializing Salesforce CLI success response for input string <date>"
- changed component to Salesforce DX
-
assigned issue to
-
reporter 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/test-xxxxxxxx@example.com.json 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!
-
repo owner - changed status to resolved
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...
-
reporter Out of curiosity, where do you see the fix has pushed? I probably checked the wrong SF repo?
-
repo owner This is the link that was sent to me:
https://github.com/forcedotcom/cli/blob/main/releasenotes/README.md
-
reporter Ah then the repo is correct, they just not developing it in the open Thanks!
- Log in to comment