Bug with Saving New Resource

We are using Retool Cloud. As of today, it's impossible to create/edit and save a resource, the resource never saves and the console shows this error, "Failed to load resource: the server responded with a status of 400 ()". And then the "Save" button is still active, because the UI doesn't see that anything is saved.

The only way I've found around this bug, is to actually save the Resource, get the error and then do a hard refresh on the browser. When you do a hard refresh the change you made gets picked up, and the Save is disabled and it works fine. Of course, this is not a great experience, as I don't want to have to do a hard refresh for every single change.

I have noticed too when making any changes to resources with "custom auth", you have to hard refresh to enable the "test workflow" button

I don't know if that is a bug or working as expected, but feels like a bug.

@ddsgadget
have you played with it in the dev console? if you haven't you may be able to check if/what errors are keeping it from working... maybe if that leads nowhere immediately, you can check to see if something related to your issue is disabled, and if so change it to enabled and see if things talk? Let us know :hamsa: na-noo na-noo

Yes, I've played with the Console. Error is above. It has nothing to do with Errors on my end. If you hard refresh the page, it works. So the data is saving fine (there is no backend issue), but the state is not updated. What is happening is that you have some sort of bug in your end with the Save button and how you are updating your state. 100% of the time, if a hard refresh fixes an issue in an app, then there is a bug in client side code with state.

And I don't mean to say this is a serious bug. It's not. It's just very annoying when we update a resource to have to refresh the entire page.

Yes, exactly. The bug happens with "custom auth". Thanks for verifying you experienced the same thing.

Hello @ddsgadget!

A 400 error is caused by a Corrupted browser cache – where using corrupted cache files in a request may cause the server to misinterpret it, leading to a 400 error. This can be fixed by clearing cookies, have you tried clearing your cookies?

I was just testing out making a new resource and you are correct the display on the save button should have a more clear color change after being clicked to show that the new inputs have been saved, this is something I can add a feature request to our engineering UI/UX team to implement.

After I changed a value in my resource, when I clicked "save changes" there is a very brief flash of a loading circle in the middle of the page, which seems to signify the changes have been saved properly. Is this showing up for you?

Instead of hard refreshing the page after clicking "save changes", I instead clicked on the back arrow button to the left of the Resource title/logo to go back to my '/resources' page. Then when I clicked back into the resource my saved changes have persisted.

Let me know if you are able to replicate the steps I listed above, as I think the save button works without a hard refresh it just doesn't give appropriate visual feedback which is something we can fix.

Is the hard refresh related to the 400 error?