Help with "Instance is not unique" when updating an entry

I had this simple schema with some basic fields. Initially it had a single field (stripeID) with a @unique tag to it. All was working fine. Yesterday, I added a second field (email) also with a @unique and my updateOrganization mutation now keeps returning an “Instance is not unique error”.

Bear in mind I had two other entries before this change, I have added a third entry after the change. I have added the unique email to both of the existing entries and have made certain the third entry does have a unique email and stripeID fields.

Anybody able to shed any guidance on how to resolve this? I am not trying to create new entries, that works fine. It’s updating an existing entry that is the issue.

Hi @dipscom!

To clarify, can you share the latest schema (at least just the relevant type) and also the mutation you are trying to run?

Also, how many documents are in the relevant Collection? Just 3? Are you able to share?

  Lambda('ref', Get(Var('ref')))

Hi @ptpaterson,

Here are (what I think) the relevant bit that you have asked to clarify:

type Organization {
  maxSpecialties: Int
  maxUsers: Int
  name: String
  specialties: [Specialty] @relation
  stripeID: ID @unique
  email: String @unique
  subscriptionLevel: String
  teams: [Team] @relation

type Team {
  members: [User!]! @relation
  name: String!
  organization: Organization!

type User {
  email: String! @unique
  firstName: String
  lastName: String
  netlifyID: ID! @unique
  role: String!
  showTutorial: Boolean!
  team: Team!

type Specialty {
    name: String!
    organization: [Organization] @relation
    subSpecialties: [SubSpecialty] @relation(name: "sub_specialty")

type SubSpecialty {
  name: String!
  specialties: [Specialty!]! @relation(name: "sub_specialty")
  illustrations: [Illustration] @relation

type Illustration {
  name: String
  src: String
  default_illustration: Boolean
  subSpecialties: [SubSpecialty] @relation

type Query {
  findOrganizationByEmail(email: String!): Organization!
  findOrganizationBystripeID(stripeID: ID!): Organization!
  findUserByNetlifyID(netlifyID: ID!): User!
  findUserByEmail(email: String!): User!

The mutation is the following:

mutation ($id: ID! $specialties: [ID] $maxUsers: Int $subscriptionLevel: String) {
  updateOrganization (id: $id, data: {
    maxUsers: $maxUsers
    specialties: { connect: $specialties }
    subscriptionLevel: $subscriptionLevel
  }) {
    specialties {
      data {

The number of documents are not large (at least to my understanding of such things), the response from the mutation should yield less than a dozen.

Now, having spent some time tinkering and trying different things, I seem to have isolated the issue to being to do with the “{ connect: $specialties }” - If the mutation tries to connect a set of $specialties where a set already is connected - regardless of being the same set or not, the “Instance is not unique” error is seen. I can disconnect and connect but not change the set that is being connected.

Ah. Yes!

When you create a many to many relationship, Fauna generates a link-table-like collection to store the connections. It also creates a unique index on that collection.

you should see one in your DB named something like: organization_specialties_by_organization_and_specialty

The provided nested mutation does not check for existing connections, it immediately tries to create the new ones. Finding any existing connections, the query will fail. Fauna does not like making assumptions that everyone wants to use more expensive operations, and so leaves it up to us to implement more advanced things, if we want them.

I hope that at least explains why the error is happening, and that it is intentional.

You could create your own custom resolver like, “updateOrgSpecialties”, that provides some handling of duplicates. If so, and you are looking for help, I suggest starting a new post for “Custom resolver for handling duplicate connections” or something like that.

Or even post a feature request for a new “safe” connect nested mutation. Maybe that way, users could choose to use the simple connect mutation, or a more expensive one that handles duplicates.

Right, I see.

Your explanation does help with my understanding what is going on. Knowing it is an intentional response and why it happens is great.

The next step, then, read up on custom resolvers and see if I can write one that will accomplish what I need it do do.

Databases and backend stuff are definitely not my forte. But I’ll get there.

Thank you for your help.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.