Not retrieving all selected files

Issue #1829 new
Matthew Scholtz created an issue

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 (9)

  1. Scott Wells 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.

  2. Scott Wells 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.

  3. Matthew Scholtz 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] wasnt retrieved because ExperienceBundle isnt 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.

  4. Scott Wells 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.

  5. Scott Wells 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.

  6. Matthew Scholtz 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!

  7. Scott Wells 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.

  8. Scott Wells repo owner

    I take it back. IC2 is actually properly handling the included messages. The issue is really more in how Salesforce defines SUCCEEDED 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 as SUCCEEDED but with less retrieved components than expected as a warning (yellow vs. green notification):

    Issue_1829.png

    Are you not seeing that same behavior? If not, what does this type of retrieval look like for you?

  9. Log in to comment