prisma1
prisma1 copied to clipboard
[Mongo] Unique constraint violated error on non-unique field
When creating a new node I get a unique constraint violated
error, even tho the schema does not mark the field to be @unique
.
The field used to be @unique
, but not anymore.
called createContact mutation:
const result = await prisma.$graphql(CreateContactMutation, {
name: 'NAME',
linkedin: 'https://www.linkedin.com/in/LINK/',
...
});
Error:
{ Error: A unique constraint would be violated on Contact. Details: Field name = linkedin
at BatchedGraphQLClient.<anonymous> (/home/finn/Projects/imde/services/susi-botnet/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:77:35)
at step (/home/finn/Projects/imde/services/susi-botnet/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:40:23)
at Object.next (/home/finn/Projects/imde/services/susi-botnet/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:21:53)
at fulfilled (/home/finn/Projects/imde/services/susi-botnet/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:12:58)
at process._tickCallback (internal/process/next_tick.js:68:7) result: { data: null, errors: [ [Object] ], status: 200 } }
Schema:
type Contact {
id: ID! @id @unique
name: String!
linkedin: String!
status: ContactStatus!
...
}
Mutation:
const CreateContactMutation = `
mutation (
$name: String!
$linkedin: String!
$dateTime: DateTime!
) {
createContact(
data: {
name: $name
linkedin: $linkedin
...
Versions: Prisma CLI version: prisma/1.31.1 (linux-x64) node-v10.14.1 Docker: FROM prismagraphql/prisma:1.31
Prisma Server Logs:
{
"key":"error/handled","requestId":"local:cjuv37pv500430755c79fgg9x",
"clientId":"default_default",
"payload":{"exception":"com.prisma.api.schema.APIErrors$UniqueConstraintViolation: A unique constraint would be violated on Contact. Details: Field name = linkedin","query":"\nmutation (\n $name: String!\n $linkedin: String!\n $dateTime: DateTime!\n) {\n createContact(\n data: {\n name: $name\n linkedin: $linkedin\n createdAt: $dateTime\n updatedAt: $dateTime\n createdAt: $dateTime\n }}\n }\n ) {\n id\n }\n}",
"variables":"{\"name\":\"name\",\"linkedin\":\"https://www.linkedin.com/in/name/\""}","code":"3010",
"stack_trace":"com.prisma.api.connector.mongo.impl.CreateNodeInterpreter$$anonfun$1.applyOrElse(CreateNodeInterpreters.scala:20)\\n com.prisma.api.connector.mongo.impl.CreateNodeInterpreter$$anonfun$1.applyOrElse(CreateNodeInterpreters.scala:18)\\n scala.PartialFunction$Lifted.apply(PartialFunction.scala:224)\\n scala.PartialFunction$Lifted.apply(PartialFunction.scala:220)\\n com.prisma.api.connector.mongo.DatabaseMutactionInterpreter.$anonfun$applyErrorMapper$1(NestedDatabaseMutactionInterpreter.scala:17)\\n com.prisma.api.connector.mongo.extensions.SlickReplacement$.$anonfun$run$1(SlickReplacement.scala:24)\\n scala.concurrent.Future.$anonfun$flatMap$1(Future.scala:303)\\n scala.concurrent.impl.Promise.$anonfun$transformWith$1(Promise.scala:37)\\n scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)\\n java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)\\n java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)\\n java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)\\n java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)\\n java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)",
"message":"A unique constraint would be violated on Contact. Details: Field name = linkedin"}
}
The new Admin dashboard (which is awesome btw!) shows the field as linkedin String!
any updates?
Hey, sorry for the late response.
I just tried this out on a fresh service running 1.34 and could not reproduce the error. I set up a datamodel with a unique field that errored on duplicates. I then removed the unique property, deployed and could then write duplicated names.
My guess would be that there was a bug on an earlier version that let to Prisma missing that it should have removed the unique constraint. Could you try making the field unique again, then deploying, then removing the unique and deploying again? This might solve your problem since I suspect Prisma does not know that there is still a unique constraint on the db level. If this does not work you could manually remove the unique constraint from the db to get Prisma and Mongo in a consistent state again.
I hope that helps. If it does not work as expected after you restored a consistent state let me know and I can try to investigate more.