Unable to find type ExperienceResource in registry #2634
Comments
|
Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support. |
|
Hello @renanlq 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
github-actions
bot
added
more information required
|
Try to updated version. @salesforce/cli versionEven unistalling globaly, and instaling again, my version keeps: 2.21.8 |
|
Hello @renanlq 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
|
Try to use @latest on install command Any proxy configured on npm: |
|
Hello @renanlq 👋 None of the versions of Shared: Update to the latest version of Salesforce CLI (docs) and confirm that you're still seeing your issue. After updating, share the full output of |
|
Hello all! I'm experiencing the same issue, even after updating sf to nightly release: |
|
Hi everyone, I'd to make some changes from my network side, due to some blocks downloading the Deploy: |
github-actions
bot
added
investigating
|
I'm not able to reproduce this running the same commands and the same CLI version as reported here. I used the Salesforce sample apps, dreamhouse-lwc and ebikes-lwc. I also used a project that contains the latest community metadata type, That said, it's just a warning that is being displayed and should not cause the command to hang. Here are some things to do:
|
|
Hi @shetzel, Thanks for the feedback, so that I have tried some different commands, meanwhile, in order to not block our developments from our side we back to use sfdx cli, with same sf version intalled, for some orgs. About the Community Experience Site, yes we have an old version that is running and commited in our git source, and due to we run Org Deployment, the metadata is inside our project sctructure. I'm checking now if any update about this sctructure is impacting the use of --source-dir our --metadata parameters. Today I have tried again with sf cli, instead of using metadata I've used manifest, and any warning was triggeret when trying to validate our package on our Production Org (Release Winter'24): So that when tring to use same command but in a Preview Sandbox (Release Spring '24): So that I noticed that the warning seems to be releated to the new Release that is comming Spring '24. Add information, my version of Node and sf cli still the same. And here the the deploy commnad with --dev-debug flag: I spend about 10 minutes waiting any change after Warning message, with no update from CLI side and sandbox Deployment Status page. |
|
Hi @shetzel, We have made some tests from our side, and the Warning message only appears with deployments running on preview sandbox Release Spring '24, due to we have refreshed one of our sandbox from Production, keeping Release Winter '24, and the deploy (--manifest, --source-dir or --metadata) command in this new sandbox does not reach the Warning message mentioned in this issue. |
|
The warning messages are just warnings and should not cause the deploy to hang. You can try setting I would increase the command wait value to 60 to give it more time. When new major releases of Salesforce are rolled out it is common for things to take longer. This doesn't appear to be a problem with the CLI. If you run the same command against the same sandbox (Spring '24) with an older version of the CLI I think it will take the same amount of time. |
|
Hi @shetzel, I understood about Warning messages usually not hang the deploy, but as I mentioned, only in Preview Sandbox this scenario is happening, seems to be something related to the new Release, and I keep the terminal opened after my last message, and the comand still in stucked in Warning message for more time, with any update from cli as TIMEOUT message, or Sandbox side, any new deploy Id with Failed or Canceled status on logs in Deployment Status page in my Sandbox. But we will try with a --wait with a high value ;) Additionally We'll try to upate the config In parallel we are searching for something inside Release Notes, that could help us about "ExperienceResource". Sandbox Non-Preview with Release Winter '24: Sandbox Preview with Release Spring '24: I'll post sooner the full logs here, just to keep it logged here. |
|
Hi, Sorry for being so anoying. I'm getting some more evidences to add here, full log from both sandboxes. And, just to mention we are planing to open a case with Salesforce support, due to we already have 2 cases open due to new Release issues on Sandbox Preview, both cases has already open posts in trailhead: Spring '24 Voice Call Page UI Issue and 'Accept' button on cases not working in Spring 24, maybe this could be and issue from environment side, not cli as you mentioned. |
|
By setting this:
That is not related to the CLI, but to server side changes and resource limitations when Salesforce major releases roll out. You're best course of action right now is to open a case with Salesforce support about deploys to your sandbox being stuck, or at least taking much longer than normal. |
|
Hi @shetzel, Got an update about this topic, as you mentioned about the wait time, I'd increased the time an got a feedback, but after almost 2 hours after. :P Sandbox Preview with Release Spring '24: With this feedback I'd found some issues created in the past, with similar cenario:
And found this documents about conflict config to:
So that I'm changing the environment variable Additionally, we created the case with Salesforce support to evaluate it to, but I keep the doublt about why this conflict Error message are not affecting sandbox Non-Previews. |
|
Hi @shetzel We've got an update from Salesforce support side, and unfortunatelly they do not accepted the issue from Org side, the conclusion of my case: So that, I've changed Is this With this ENV variable configured the result was: So that we added With the non-preview sandbox, any change, the deploy command runs well, with or without the ENV variable set. Need to ask, when the source-track was change and impact the deploy command? I'm asking this due to a week before of the creation of this issue, we weren't being impacted for this conflicts. |
No. There appear to be several things going on:
|
|
This issue has been linked to a new work item: W-14870967 |
|
Hi @shetzel, Understood about the source tracking, however we already have the source of trough in our git repo, so that the source tracking inside the sandbox seems to be unecessary, since we will allways deploy on the sandbox what is in our repository. Additionlly, I've asked when the source tracking was an gate that triggers Warning and need to be configured to be ignored in our deployments, due to the fact that when we have enalbled DevHub and some dependencies an year ago, any Warning or Error with source tracking were noted or triggered since then, so I feel that the new Release in some way is making the conflicts evaluation mandatory from Org side, with or witouh From our side, We'll try to make some changes about config in our project and CI/CD steps (pipeline as code). Best regards |
|
Hello, @renanlq have you resolve your issue about "Error (1): There are changes in the org that conflict with the local changes you're trying to deploy." ? I have the same issue since sfdx command to sf command change |
|
Hello @nicolashamez-dev, here is something you might wanna try: We where facing the same problems described here in our org when running In short, we discovered you can disable source tracking locally, by running the following command in the sfdx project folder:
After that the issue was gone. Of course there is the possibility of disabling source tracking for sandboxes in the devhub org (Setup > Development > Dev Hub), and refresh the sandbox. That might disable it directly in the sandbox, but we didn't try that yet. Here's the sf command reference link: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
When trying to deploy a single Permission Set, using sf project deploy command, I'm receiving an warning massage, and so that any chages hapens, the command seems to be stuck.
Steps To Reproduce
Expected result
Just validade the build of the Permission Set, checking sintax inside it, due to we are using dry-run flag.
Actual result
Command seems to be stuck, any response are given since, we get "Warning: Unable to find type ExperienceResource in registry" message.
System Information
Which shell or terminal are you using? VSCode terminal (node);
Full output of the sf version
The text was updated successfully, but these errors were encountered: