Pre-update execution history wiped and broken Gmail credentials after upgrading to 2.17.4 on AWS ECS

Questions
1

Hello everyone,
We recently updated our production n8n instance to version 2.17.4 (on April 28th), and we experienced two critical issues that impacted our operations. I’m hoping someone can shed some light on what might have happened during the upgrade process.
Our Environment:

  • n8n version: 2.17.4

  • Hosting: AWS ECS (Docker)

  • Database: AWS RDS PostgreSQL (db.t3.small instance)

  • Execution mode: Regular

The Issues:
1. Execution History Prior to the Update was Wiped
After the update on April 28th, all of our execution history prior to that exact date completely disappeared. Our workflows are all perfectly intact (which confirms our RDS database wasn’t wiped). Also, I noticed today that new executions are being saved normally (I can see logs for April 28th and April 29th).
It seems the update process itself wiped all the previous logs in our PostgreSQL database. Because of this, we lost important form submission requests (webhook triggers) that hadn’t been processed yet.

  • Note: The variables EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE are not explicitly declared in our ECS JSON/environment variables, so we are relying on defaults.

2. Gmail Credentials Broke
Our Gmail OAuth credentials threw authentication errors immediately after the update and had to be manually re-authenticated/recreated.

  • Note: We double-checked, and the N8N_ENCRYPTION_KEY is declared in our ECS JSON and is exactly the same as before the update. Since the workflows loaded fine from the Postgres DB and the key is correct, we are confused as to why the credentials broke.

My Questions for the Community:

  • Did version 2.17.4 (or the 2.x family) introduce any changes to how database migrations or default pruning routines handle execution logs during a major update on PostgreSQL? Is it expected behavior for the upgrade to truncate the executions table?

  • Why would the Gmail credentials fail to decrypt/authenticate if the N8N_ENCRYPTION_KEY remained completely unchanged during the ECS task deployment?

Any insights or recommendations on how to configure our .env or ECS Task Definition to prevent this from happening in future updates would be highly appreciated.
Thank you!

3

Hi @Heraldo_Ecard , welcome to the n8n community !
Can you confirm the effective runtime values for EXECUTIONS_DATA_PRUNE , EXECUTIONS_DATA_MAX_AGE , EXECUTIONS_DATA_PRUNE_MAX_COUNT , and N8N_ENCRYPTION_KE` in the ECS task that actually started after the upgrade?

Also, do the n8n startup logs show any database migration, pruning, or credential decryption errors around the first boot on 2.17.4?