Adding a col to PostgreSQL database caused indefinite hang

I recently deployed a migration to production that added a new column to a table. The migration was very simple and should have only locked the table for milliseconds: ALTER TABLE "table_1" ADD COLUMN "last_status_update" TIMESTAMP(3); However, it seemed to hang indefinitely when deployed, causing application downtime. During the downtime, I ran the following command and exported the results:

SELECT pid, age(clock_timestamp(), query_start), state, wait_event, query 
FROM pg_stat_activity 
WHERE state != 'idle' 
ORDER BY query_start;

Unfortunately, I didn't think to do something similar with pg_locks. When I manually killed the transaction and ran the same command by manually connecting to the database, it resolved almost immediately without issue. I can't figure out why the ALTER TABLE seemed to hang. I thought it might be a developer holding an open transaction as described in [this answer](https://dba.stackexchange.com/a/133047) , but I think we would have seen that idle in transaction query in pg_stat_activity if that was the case. The table in question table_1 is small, ~11k rows. There are no constraints besides a PRIMARY KEY constraint. No indexes besides primary key as well. No virtual columns or triggers. In case it's relevant, we're using Prisma as an ORM. I considered that maybe Prisma failed to release the [advisory lock that it holds during migrations](https://www.prisma.io/docs/orm/prisma-migrate/workflows/development-and-production#advisory-locking) , but I believe advisory would have shown up as the wait_event instead of relation. Anyone know what might be going on? Thanks in advance :)