- edited description
Not retrieving all selected files
Today in a sandbox am trying to retrieve components from SF and IC is repeatedly failing to retrieve all the files I selected, I keep getting log messages like:
Retrieve Complete: Retrieved 2713/2820 components from [my connection] in 4 m 18 s 258 ms with status SUCCEEDED.
and
Retrieve Complete: Retrieved 7/80 components from [my connection] in 51 s 37 ms with status SUCCEEDED.
and even
Retrieve Complete: Retrieved 0/37 components from [my connection] in 12 s 501 ms with status SUCCEEDED.
strange definition of Succeeded there…
There may be a pattern to which components are failing but I haven’t tried yet to pin that down. But as I have tried repeatedly, some files which didn’t retrieve in a previous try have been retrieved in a subsequent one, which is odd.
I have tried this using both API v51 and v49.
Thanks for your help!
Comments (10)
-
reporter -
repo owner Matthew, I probably won't get to take a look at anything until the beginning of next week (I live in Texas and, while we're all good, let's just say I'm distracted!), but can you please enable debug logging for metadata retrieval, reproduce the issue, and either attach or email all
idea.log*
files that include relevant information about that retrieval? That will ensure that I have what I need to help understand what's happening. -
repo owner Matthew, I'm finally circling back around to this. Sorry for the long delay. Assuming this is still reproducible, can you please enable debug logging for metadata retrieval, reproduce the behavior, and either attach or email the resulting
idea.log
? Please also clearly specify the expected/desired set of retrieved metadata just in case whatever filtering is taking place is happening so early that the log only shows the filtered set. -
reporter Hey Scott, I too have not had time to come back to this in earnest. But today I was trying to retrieve one file (ExperienceBundle) and was getting the old “Retrieved 0/1 components with status SUCCEEDED” result. I pulled the log as you suggested and there was an error reported there that I was missing a setting in my org, and after correcting that the retrieve went through. So not IC’s fault it couldn’t get the file in this case. In the past I’m sure there were different reasons for various failures.
But what I would request from IC would be not call a retrieve a success if there’s an error, and report the error to me in the in-app event log, without making me go through debug logging to find out what the problem is.
Here’s today’s err from the log:
{ "done": true, "fileProperties": [ { "createdById": "[foo]", "createdByName": "Percolator Consulting", "createdDate": { "orig_year": 2021, "orig_month": 5, "orig_day": 19, "orig_hour": 23, "orig_minute": 48, "orig_second": 38, "orig_fracSeconds": 0.250, "orig_timezone": 0, "year": 2021, "month": 5, "day": 19, "timezone": 0, "hour": 23, "minute": 48, "second": 38, "fractionalSecond": 0.250 }, "fileName": "unpackaged/package.xml", "fullName": "unpackaged/package.xml", "id": "", "lastModifiedById": "[foo]", "lastModifiedByName": "Percolator Consulting", "lastModifiedDate": { "orig_year": 2021, "orig_month": 5, "orig_day": 19, "orig_hour": 23, "orig_minute": 48, "orig_second": 38, "orig_fracSeconds": 0.250, "orig_timezone": 0, "year": 2021, "month": 5, "day": 19, "timezone": 0, "hour": 23, "minute": 48, "second": 38, "fractionalSecond": 0.250 }, "manageableState": "UNMANAGED", "type": "Package" } ], "id": "[foo]", "messages": [ { "fileName": "unpackaged/ExperienceBundle", "problem": "[experienceName] wasn’t retrieved because ExperienceBundle isn’t enabled for Aura sites. To enable ExperienceBundle, in Setup, select Enable ExperienceBundle Metadata API in Digital Experiences | Settings." } ], "status": "SUCCEEDED", "success": true }
I see that the response there has status: SUCCEEDED, but clearly it didn’t succeed. Is IC looking at the messages/problem nodes in the response?
Thanks!
M.
-
repo owner Thanks for the relevant log entry, Matthew. The issue is that the CLI isn't consistent about where it adds errors in the response JSON document. I've had to add about 3-4 distinct places in the JSON response where IC looks for errors, all but one added organically based on exceptions, and it looks like I'll need to add yet another.
Tomorrow's build is already ready to go, but I'll address this for next week's build.
-
repo owner Matthew, I'm actually going to need a bit more context on this one as the JSON here doesn't at all match up with what's expected for a response from
force:source:retrieve
. Do you mind sending a log of the full operation? Feel free to email if you'd prefer vs. posting it here. -
reporter Hey Scott. this is happening again with a different org/repo and updated IDE and IC.
Just did a retrieve and got this message:
5:41 PM Retrieve Complete: Retrieved 10/69 components from xxx in 2 s 581 ms with status SUCCEEDED.
I will send you the log via email. If you decide you need “a log of the full operation” as you asked back on 5/20, please send me instructions on how to do that as I’m not sure what that means.
Thanks!
-
repo owner Thanks, Matthew. This is like the previous one where there are
messages
that aren't considered part of the actual retrieval status. As we discussed a few months ago, I'll update IC2 to include this information in the retrieval details. -
repo owner I take it back. IC2 is actually properly handling the included
messages
. The issue is really more in how Salesforce definesSUCCEEDED
in a retrieve response, but IC2 should be including all of the details in the Messages tool window, and it should be flagging a retrieval that was marked asSUCCEEDED
but with less retrieved components than expected as a warning (yellow vs. green notification):Are you not seeing that same behavior? If not, what does this type of retrieval look like for you?
-
repo owner - changed status to resolved
Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.
- Log in to comment