Hi all -- I'm having trouble following the guide for the expand-contract pattern in the context of a rolling deploy where two versions of my prisma client are running at the same time. Steps 1-6 work just fine, but Step 7 asks me to remove a column from my schema. When I do that, the new prisma client expects the column to be removed whereas the old prisma client expects the column to be present. During the rolling deploy, code reliant on the old prisma client will throw errors, even if I don't refer to that column anywhere in my code. I'm guessing because it's performing a

SELECT *

, and trying to map column values into required fields in the resulting JS object. Any advice on what to do here? Is there a way for me to exclude a field from my prisma client without modifying the underlying database schema?

Are you rebuilding your clients in that time?

Yeah - the new prisma client is built in CI and deployed in a gradual rollout. The old prisma client runs in production unchanged, until the deploy is complete.

Okay, what about a recompile of the old code with the new schema?

That's the precise step I'm taking -- I'm not changing the code on top of my prisma schema and prisma client. I'm only altering my prisma schema to remove a field. The new prisma client is generated without that field.

Do you have any blocks up for those changes? Maybe add a header, and filter out requests that have that header? It isn’t a solution, but it could be a work-around.

oh, do you mean like to block requests from the frontend to the backend if they have a certain http header?

Yes.

that's an interesting idea, but I'm not sure I could block requests in a controlled fashion. They all funnel through a load balancer and get distributed evenly between code running on old servers and code running on new servers during a deploy

Write it in your code.

I could, but the net result would be that the user sees half of their requests succeed and half of their requests fail on the frontend