Internal network proxy cache issue: Deploy failing with 28P01 despite matching passwords / working public DSN

Question

Hello Railway Support Team,

I am running into a persistent internal networking issue after rotating the `POSTGRES_PASSWORD` on my Postgres service.

My app (`dcc-v2-app`) is failing to deploy because the internal database connection throws a `28P01` (password authentication failed) error during the build phase. However, I have verified that the credentials are correct.

Here is the hard evidence of the paradox:

1. **Public DSN works:** If I connect using `DATABASE_PUBLIC_URL` from my local machine using the exact same password, authentication succeeds perfectly.
2. **Hashes match:** I have verified that the password hash on `dcc-v2-app`'s `DATABASE_URL` is 100% identical to the Postgres service's `POSTGRES_PASSWORD` and `DATABASE_PUBLIC_URL`.
3. **The failure is strictly internal:** The deployment (using the internal `postgres.railway.internal` DSN) fails with `28P01`, even though the exact same password string works externally. Restarting the Postgres service did not clear the issue.

**Example Failed Deployment ID:**`22b46015-9b94-460e-a5b9-ce8ae0eb3b5e`

It appears that Railway's internal TCP proxy or network layer has cached a stale connection state or is failing to route the new credentials properly for internal VPC connections.

Could you please investigate and flush the internal network cache for my project so the internal DSN resolves correctly during deployment?

Thank you!