Prisma1: Deployment won't end

[marktani]

@jhalvorson commented on Sat Mar 03 2018

hey, I’ve been experiencing this issue for the past day or two and can’t see what’s up. When I run prisma deploy to prisma cloud I get this:

Deploying` service `XXX` to stage `dev` on cluster `XXX` 1.3s

Changes:

  Class (Type)
  + Created field `lowerTitle` of type `String!`

  User (Type)
  ~ Updated field `avatar`

  FileToUser (Relation)
  + Created relation between File and User

Applying changes (12/3) ⡿

It just sits there spinning until I kill it, never ends.

However, when I view my deployment history on app.prisma.sh I see that it looks like it worked:

Jamie added 1 field, updated 1 field, added 1 relation.
4 minutes ago

But when I view the Data Browser I can’t see my new fields. Local stuff all works fine, just deployments to prisma cloud aren’t working for me.

[marktani]

Hey @jhalvorson, can you share the "before" and "after" schema?

[jhalvorson]

Hi @marktani,

I removed the new field of 'avatar' (relation to File) and removed the @unique constraint from 'lowerTitle', redeployed and that worked fine. I then re-added avatar back, redeployed and all was fine.

I think the issue was the @unique constraint as they were defaulting to empty strings. On the first redeploy I got this error:

Applying changes !
 ▸    java.sql.SQLIntegrityConstraintViolationException: (conn=28871) Duplicate entry '' for key 'lowerTitle_UNIQUE'
 ▸    at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:157)
 ▸    at org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:106)
 ▸    at org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:235)
 ▸    at org.mariadb.jdbc.MariaDbPreparedStatementClient.executeInternal(MariaDbPreparedStatementClient.java:224)
 ▸    at org.mariadb.jdbc.MariaDbPreparedStatementClient.execute(MariaDbPreparedStatementClient.java:159)
 ▸    at com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
 ▸    at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute(HikariProxyPreparedStatement.java)
 ▸    at slick.jdbc.StatementInvoker.results(StatementInvoker.scala:39)
 ▸    at slick.jdbc.StatementInvoker.iteratorTo(StatementInvoker.scala:22)
 ▸    at slick.jdbc.Invoker.first(Invoker.scala:31)
 ▸    at slick.jdbc.Invoker.first$(Invoker.scala:30)
 ▸    at slick.jdbc.StatementInvoker.first(StatementInvoker.scala:16)
 ▸    at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:52)
 ▸    at slick.jdbc.StreamingInvokerAction$HeadAction.run(StreamingInvokerAction.scala:51)
 ▸    at slick.basic.BasicBackend$DatabaseDef$$anon$2.liftedTree1$1(BasicBackend.scala:240)
 ▸    at slick.basic.BasicBackend$DatabaseDef$$anon$2.run(BasicBackend.scala:240)
 ▸    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 ▸    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 ▸    at java.lang.Thread.run(Thread.java:748)
 ▸    Caused by: java.sql.SQLException: Duplicate entry '' for key 'lowerTitle_UNIQUE'
 ▸    Query is: ALTER TABLE `backend-production@dev`.`Class` ADD COLUMN `lowerTitle`
 ▸    mediumtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL , ADD UNIQUE INDEX `lowerTitle_UNIQUE` (`lowerTitle`(191)
 ▸    ASC), ALGORITHM = INPLACE
 ▸    at org.mariadb.jdbc.internal.util.LogQueryTool.exceptionWithQuery(LogQueryTool.java:146)
 ▸    at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.executeQuery(AbstractQueryProtocol.java:217)
 ▸    at org.mariadb.jdbc.MariaDbPreparedStatementClient.executeInternal(MariaDbPreparedStatementClient.java:218)
 ▸    ... 15 more
 ▸

All is working again though.

[cameronk]

I've been experiencing this as well. I dove into my database and looked at the Migrations table, found this under errors (snipped out my info):

...
Duplicate column name 'source'\nQuery is: ALTER TABLE `(snip)`.`Person` ADD COLUMN `source`\n         varchar(191) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL , ALGORITHM = INPLACE\n\tat 
...

My issue was that I had forgotten to remove an @rename directive after the migration ran. It would be really nice if Prisma gave me a warning after running a deployment with these.

In any case, Prisma should return an error instead of just hanging eternally.

[do4gr]

@jhalvorson was right on the money with his guess.

Setting a unique constraint will error if there are already duplicates present in the case of a field update or if a new field is required and unique since SQL will set default values for the newly required fields. I'm closing this issue since it seems to show symptoms of this problem. With the deploy changes from 1.6.1 and this PR the issue should be fixed #2371
If anyone is still experiencing problems please open a new issue with a reproduction.