In our application, we very often run into users being greeted with pages that do not have any of the data populated. It is similar to how the page looks when the authorization token has expired. Initially this is what I thought the problem was (even though they were not being greeting with the authenticate resource popup) and instructed them to login with an auth button in our application. However, they have to do this extremely frequently which is problematic. Anyway, when they are greeted with the unpopulated page reloading the page will actually then work and the data will get populated. No need for them to relogin. So it is basically like the Salesforce resource queries sometimes just do not run on page load.
For reference this is what our page would look like when the data is not being populated:
These users experiencing these problems do have use access to our Salesforce resource and it will pull in the information after a reload and for a brief period after when users go to the page again but after some time they will once again be greeted with no data populated and need to refresh the page. This happens to me as well on occasion as the admin.
I had a user open the dev console in their browser to see if there were any errors and they did report back a log with some 400 errors. The 403 errors make sense I suppose as that user just does not have access to those queries in the 403 errors. But the 400 error queries they do have access to and will load for them on a refresh: (the component is orphaned stuff is not relevant, something I need to fix down the line haha)
I will sometimes come up against this data not populating as well, though when I open the console, I do not see any direct 400 errors but looking at the network tab I do see that no get requests were ever made. It will just be one post request whereas when the app is functioning there will be a number of requests:
It feels like the user is just timing out way too soon and then clicking reload is "reauthorizing" and allowing the queries to go through.
I am using the cloud version of Retool so it does not seem there is any way to really control when users would need to reauthorize in Salesforce but they are never being told they need to reauthorize. The data just won't load frequently until they refresh and then the queries will activate. Not sure if this is just a strange thing with Salesforce integration on the cloud version. Salesforce can definitely be strange.
Thanks for any help and sorry for the long post just at a bit of a loss on what is directly the issue here and how to resolve it so users don't have to be constantly refreshing.
Hey dmull, It might be that users are being re-authed in the background at first and that process hasn't been completed by the time the page loads. To troubleshoot this issue, it would be very helpful to see a screenshot of your resource setup page. If you don't feel comfortable sharing that publicly here (which would be completely understandable), then please write open a chat with us in Support and we can help you from there!
Hello Everett, thanks for the response. That does seem like it could potentially be the issue. Attached is our resource setup. Options are pretty barebones for SF so not sure what I could change to fix this.
If this is potentially a race condition, then can you see if putting a delay on these queries that run on page load resolves the issue of having to reload?
Thanks for the page load delay tip! I should have looked for that in the query settings beforehand. I have implemented that now and am hoping that will have some positive effect if it was indeed a race condition issue. I'll be testing the next few days to see if it has fixed the problem.
As for the Salesforce timeout, we currently timeout sessions at 8 hours so probably would not be a factor in users having to reauth/refresh in Retool multiple times throughout the day. When they are using Retool and run into this problem of data not loading, they are still logged into Salesforce and can use that platform with no issue as their session has not technically expired.
It seems the issue is still going on where users will often come to a Retool page using a Salesforce resource where they will need to refresh the page before any data will populate. This is persisting even after I implemented a page load delay on all queries that run on load. Is it possible this is just some sort of bug in Retool with connecting/authorizing to Salesforce (Salesforce can definitely be weird) because we also have apps that use graphql resources that work without this issue at all? I can see an expired access/refresh token error on queries but this resolves after a page refresh and is happening way too often throughout the day.
Hey dmull, I'm sorry to hear that my suggestion wasn't helpful After taking a second look at your issue with my teammate, we're not convinced that this issue is directly stemming from the auth on this Salesforce resource. It would be very helpful for us to see the full status 400 errors your users are getting here:
It would also be helpful to get a better idea of which queries specifically aren't running and how those queries are set up. I see you have this feature selected:
Are the queries that are failing to load all using this Sungage resource or are some of them using different REST API resources? Is there a clear delineation between the queries that are failing to load with status 400 errors and those that are failing with status 403 errors or does this appear to be random?
One other thing that is odd is that you're seeing different behavior than your users. This could indicate that the issue is somehow related to Retool permissions. Could you try promoting one of your users to the Admin group like yourself and see if they start seeing the same behavior as you?
Apologies, I am not entirely sure what is meant by full status 400 errors but clicking into the errors in the console we will see "Cannot GET /api/pages/uuids/00b07b60-811e-11eb-9fc6-9f69550df0df/query" for all the queries triggered to run on page load.
All of the queries that are failing to load are using this Sungage resource. In this application we are only using that one Salesforce resource.
There is a clear difference between those with a 403 and 400 error. The 403 errors make sense for the user that was getting them because I disabled those queries for their user group. The 400 errors make less sense and again once they refresh the page (no need to even full reauth) those queries will then run fine and they will see what they need to see populated.
For this last point about seeing different behavior, this was actually somewhat related to my browser. I would run into the exact same problem the other users were running into (i.e having to refresh very often to get the data to populate). The only difference was I would not see any 400 errors (or errors at all) in the dev console. This was on Firefox. However most of our users use chrome so I have been trying it there and now I will actually see the 400 errors for my user as well which is sort of strange. But either way, I do see the same logged errors as my users now and also another admin user has seen these errors in the dev console before when encountering this issue (also using a chrome broswer) when I was not seeing the console errors in Firefox.
Looking at the queries themselves that are erroring out in the Retool edit mode (which switching into edit mode when the error is happening will solve the error anyway since the request is made again and the data will then populate after that request) when I am already in that mode and encounter this problem, I just get the classic "expired access/refresh token".
Since this gets resolved when a user refreshes their tab it seemed like it was just some sort of miscommunication between Retool and Salesforce when it comes to refreshing authorization that Retool isn't grabbing from Salesforce until a decent amount of time after the page loads which is why then reloading the tab will work with bringing data in but I am not sure obviously haha. I did add a decent amount of page load delay on the queries that run on page load but that did not solve the issue and adding any more time would be kind of too slow for users anyway.
Thanks again for looking into this and let me know if any more info would be useful!
Few follow-up questions - when you see the failed queries, are any of the salesforce requests successful? Are any of the queries completely static or hardcoded (meaning they do have input values that would need to be calculated on page load)?
Also, could you share the response from the failed queries from inside the browser console? Such as:
So when the requests are failing, it is every Salesforce request that is failing.
Most of the queries do actually have some sort of variable value since I am pretty much always using a url param in the where clause or the id value of a different query. For example:
SELECT Id, lots of different fun fields here
FROM Credit_Application__c
WHERE Id = '{{urlparams.id}}'
I will share the response from inside the console next time I get this error. I recently reauthed so it probably won't happen again today as the day is almost over here but I wanted to at least answer the other questions first. Thanks for your time!
I'd be curious if we added a completely hardcoded query that returns any sort of data if that would return results. Can be as simple as SELECT Id FROM Account LIMIT 1. It would be very helpful if we could narrow the scope of the problem between some form of race condition and authentication of the resource itself.
So while waiting for this issue to come up again to share more info, I actually have now not encountered this problem for almost 3 days and have confirmed with other users that they have also not had this issue come up again for several days.
This is a bit odd since this is a problem we were previously encountering multiple times every day but I did not make any changes to the page within that time that would have had any effect on this. I am still hesitant to say this is no longer a problem since it has only been a few days for me and this issue had been going on for a long time before now but I am a bit perplexed on why all of a sudden the problem would appear to not be an issue anymore. Was there any change on Retool's end within the past couple of weeks that could have affected this positively?
Hmmm strange! It's difficult to say what may have changed without knowing exactly what the problem is/was (still not exactly sure if it was an authentication issue or a race condition of some sort). I haven't been able to replicate this on my end and it's not currently a known issue. It doesn't look like there were any direct changes to the Salesforce integration recently. Either way, should we monitor this and see if you can reproduce it again?
Yeah kinda weird. I will continue to monitor this for sure and if it comes back again I will be sure to get more of the response info to report back. Thanks!
After taking a second look at your issue with my teammate, we're not convinced that this issue is directly stemming from the auth on this Salesforce resource. It would be very helpful for us to see the full status 400 errors your users are getting here:
