I have a small issue with my self-hosted plan. From time to time, when I save my parameters (new URL, new parameters, new body) in a REST API Query, it stays in an indefinite loading state and doesn't save... I'm using version 3.75.7.
I am sorry you are having this issue that is very odd that this only happens from time to time.
I am not sure there is much that can be done when the save event gets stuck besides a hard page refresh that will likely not save the changes you made.
Next time this happens, can you inspect the browser and view the networking tab to get a screenshot?
There is a known bug that falsely shows infinite loading. From the network tab we will be able to see if the save action is getting stuck locally or if it is being completed but the response back to the app is the issue.
My team also encountered the same issue.....
We are on Retool version 3.75.0 and this happened when we try to save a SQL query.
Our temporary workaround is to rename the query - change the content - save - rename it back but it's annoying.
Some other symptoms:
This is at the whole app level, if the app is in trouble, all queries will not be able to save. Even if I duplicate the app in issue, the unable to save problem will be carried over.
If I add a new / delete a query, all other existing queries will now be able to save as well, until I refresh the page.
That is very unusual and definitely should not be happening, let me investigate further with our team to see if this is a known bug.
So to confirm, if the query has its name changed, it can be saved? When you mentioned this is "whole app level", some apps work fine but once an app "breaks" then every single query not just SQL fails to save?
For the second bullet point, once the queries begin to not save, adding/deleting a query fixes this issue and allows for all other queries to save again, BUT when you refresh the page the queries stop being able to save, correct?
Having nearly the same version of Retool as Samuel leads me to believe this might be an old bug that was patched that might need updating.
But even without updating there should be something we can do to remedy this. I will report back
Hi @Jack_T
I just double confirmed with the app in issue.
So basically yes, for the app in issue, not only the SQL query, the JS query cannot be saved for changes as well.
Rename any query / add a new query / delete a query will all create a temporary fix that allows all existing queries to be able to save. But if I refresh the page, all queries will back to the cannot be save state.
Very odd. I am super impressed you were able to find a work around that works
Let's first try to figure out why the save is failing. For this, we will need to look into the Network tab inside the browser's inspector.
This will give us more details on if the save request is making it to your backend server or if the save is hanging/failing before this happens. Which could explain why the frontend is getting stuck with a spinning wheel instead of an error message
If you are using nginx, it could be a known issue with the variable of CLIENT_MAX_BODY_SIZE which would need to be set larger. But this is just a hunch.
In the network browser, once you click on the 'save' event, there is another sub-tab called 'Timing' which will show where the request is timing out at.
This will confirm that the request is not making it to the server, which we can double check by viewing the server logs for the time of the save request. Or it will show us where in the frontend this save request is getting held up/lost at.
@Jack_T Just to clarify, I currently use the recommended nginx.conf by Retool as outlined here:
do you mean to add a larger client_max_body_size in both server sections?
server {
listen 80;
server_name retool.yourcompany.dev; # <- Change this to your subdomain
client_max_body_size 100M; #added here
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name retool.yourcompany.dev; # <- Change this to match server_name above
ssl_certificate /etc/nginx/certs/hatch.crt; # <- Change this to your .crt file name
ssl_certificate_key /etc/nginx/certs/hatch.key; # <- Change this to your .key file name
client_max_body_size 100M; #added here too
location / {
proxy_set_header Host $host;
proxy_pass http://api:3000;
}
}
Yes I am fairly certain that the change must be made in both locations to ensure that the server is able to handle the larger payloads of data during saves.