Bug Report: 500 error on /resources after changing ENCRYPTION_KEY

We have a fairly new self-hosted Retool instance v3.32.8 with a companion RDS Postgres v14 instance.

We recently changed our encryption key (not intentionally, but that's how it goes sometimes). We had 1/2 dozen resources, some of which contained an API key. Obviously, those resources are unrecoverable, I accept that, but their existence appears to have caused harm to the newly installed application. Loading the /resources page gives a blank page and this 500 error in the application logs:

{"endpoint":null,"error":{"level":"error","msg":"Internal server error: error:1C800064:Provider routines::bad decrypt",
"stack":"Error: error:1C800064:Provider routines::bad decrypt\n at Decipher.final (node:internal/crypto/cipher:199:29)\n at Te2 (/retool_backend/bundle/main.js:46:14744)\n at or0 (/retool_backend/bundle/main.js:46:15071)\n at F2 (/retool_backend/bundle/main.js:46:14948)\n at T0.databasePassword (/retool_backend/bundle/main.js:3695:44282)\n at T0.get (/node_modules/sequelize/lib/model.js:2168:41)\n at T0.get (/node_modules/sequelize/lib/model.js:2190:33)\n at /retool_backend/bundle/main.js:3690:10082\n at Array.map ()\n at D_2 (/retool_backend/bundle/main.js:3690:9953)\n at Pp0 (/retool_backend/bundle/main.js:3690:8262)\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async Promise.all (index 0)\n at async /retool_backend/bundle/main.js:2586:57049","type":"INTERNAL_ERROR"},"level":"info","message":{"http":{"method":"GET","request":{"time":0.09551880399999209},"status_code":500,"url_base":"http://retool.furx-stg.net","url_path":"/api/resources"},"type":"REQUEST_FINISH"},"organization":{"id":1,"name":"REDACTED"},"pid":41,"requestId":"4a6b116e-3ddc-4b21-8978-12f27129d1fb","timestamp":"2024-03-20T00:01:16.191Z","user":{"email":"REDACTED","sid":"user_REDACTED"}}

To recover, I needed to login to Postgres directly and delete a couple of records in the resources table.

I get that one shouldn't change the encryption key, as doing so makes previously saved resources un-decryptable, but doing so shouldn't cause the page to blow up.

Hi @Chas_Schley, here is a topic where @joeBumbaca goes over the two ways we can update the encryption key to fix this issue. It currently does require manual db surgery, which is not ideal. We have a Feature Request to provide a friendlier way to do this, but unfortunately, we do not have an estimated release date yet. I have attached your feedback to the request, and we'll be happy to update you here when the feature is ready.