Prisma1: Strange internal server error on prisma cloud deploy; with docker `java.util.NoSuchElementException: None.get`

[devautor]

Describe the bug
I am getting an internal server error on deploying this very simple datamodel with Prisma demo cloud (no docker). I have zeroed-down bug to this piece of SDL reproduction.

I assumed that it could be due to downtime with Prisma cloud itself, and then tried to connect to my AWS RDS instance with docker in local setting. This was also giving me a deployment error, where docker logs say: java.util.NoSuchElementException: None.get. See this issue in full detail, that I asked in the forum here.

To Reproduce
Steps to reproduce the behavior:

1. Go to line 58 in following code, and find this comment # TO GET ERROR, UNCOMMENT THESE FOUR LINES (matchConditionfield)
2. Uncomment the field definition matchCondition: CollectionAutoCurationRuleCondition!
3. prisma deploy will fail!
4. Error: ERROR: Whoops. Looks like an internal server error. Search your server logs for request ID: eu1:cjq179ltrsov80a55tl1iivmq

type Collection {
  """
  ID
  """
  id: ID! @unique
  """
  Title of the collection
  """
  title: String!
  """
  Description of this collection
  """
  description: String
  """
  Collection will be published on this date and time (in the future from now)
  """
  liveFrom: DateTime!
  """
  Collection will be published till this date and time (in the future after liveFrom's time)
  """
  liveTill: DateTime

  """
  Rules for "initial" automatic curation of this collection
  """
  autoCurationRules: [CollectionAutoCurationRule!]!
    @relation(name: "CollectionAutoCurationRules", onDelete: CASCADE)
  """
  Apply all rules in conjunction or disjunction
  """
  applyAllRules: Boolean! @default(value: "false")

  """
  Created at this time
  """
  createdAt: DateTime!
  """
  Updated at this time
  """
  updatedAt: DateTime!
}

type CollectionAutoCurationRule {
  """
  ID
  """
  id: ID! @unique
  """
  One of the rules for this collection
  """
  collection: Collection!
    @relation(name: "CollectionAutoCurationRules", onDelete: SET_NULL)
  """
  Matching rule is applied on this type
  """
  matchThis: CollectionAutoCurationRuleMatch!

  # TO GET ERROR, UNCOMMENT THESE FOUR LINES (`matchCondition` field)
  # """
  # Condition of this rule
  # """
  # matchCondition: CollectionAutoCurationRuleCondition!
  """
  Match type to this value
  """
  matchTo: String!
  """
  Created at this time
  """
  createdAt: DateTime!
  """
  Updated at this time
  """
  updatedAt: DateTime!
}

type CollectionAutoCurationRuleMatch {
  """
  ID
  """
  id: ID! @unique
  """
  Match condition against this
  """
  match: String! @unique # Tag, Category, etc.
  """
  Created at this time
  """
  createdAt: DateTime!
  """
  Updated at this time
  """
  updatedAt: DateTime!
}

type CollectionAutoCurationRuleCondition {
  """
  ID
  """
  id: ID! @unique
  """
  Condition of this rule
  """
  condition: String! @unique # e.g. IS_EQUAL_TO, STARTS_WITH, etc.
  """
  Created at this time
  """
  createdAt: DateTime!
  """
  Updated at this time
  """
  updatedAt: DateTime!
}

Expected behavior
It should deploy successfully.

Screenshots
Screenshot shows first successful deploy with comments in place, and then the error on removing that comment from the field.

Versions (please complete the following information):

• OS: Windows 10
• prisma CLI: prisma/1.23.2 (windows-x64) node-v8.11.3
• Prisma Server: [e.g. 1.9.0]

Additional context
I had asked this issue on the forum here.

[pantharshit00]

Thank you @devautor for the investigation you did and for your co-operation in this issue. We really appreciate your contribution.

I was able to reproduce this issue. Here is the reproduction repository: https://github.com/pantharshit00/prisma-forum-5462

The workaround that I have found for now is to name the relation using @relation directive. It may fit your use case.

try this datamodel:

type Collection {
  id: ID! @unique
  title: String!
  description: String
  liveFrom: DateTime!
  liveTill: DateTime
  autoCurationRules: [CollectionAutoCurationRule!]!
    @relation(name: "CollectionAutoCurationRules", onDelete: CASCADE)
  applyAllRules: Boolean! @default(value: "false")
  createdAt: DateTime!
  updatedAt: DateTime!
}

type CollectionAutoCurationRule {
  id: ID! @unique
  collection: Collection!
    @relation(name: "CollectionAutoCurationRules", onDelete: SET_NULL)
  matchThis: CollectionAutoCurationRuleMatch!
  matchCondition: CollectionAutoCurationRuleCondition!
    @relation(name: "CollectionAutoCurationRuleCondition")
  matchTo: String!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type CollectionAutoCurationRuleMatch {
  id: ID! @unique
  match: String! @unique # Tag, Category, etc.
  createdAt: DateTime!
  updatedAt: DateTime!
}

type CollectionAutoCurationRuleCondition {
  id: ID! @unique
  condition: String! @unique
  createdAt: DateTime!
  updatedAt: DateTime!
}

[devautor]

@pantharshit00 you are awesome; let me try this!
BTW could you elaborate on this behavior, why is this happening, I mean, what is Prisma expecting?

EDIT: Fix you suggested does work; but it's still strange for me! Would wait to know more on this 👍

[jpj625]

Also encountered this issue, also fixed by applying names to inferable relations.

[do4gr]

Hey @devautor and @jpj625 ,
thanks for reporting this. I looked into the issue and you are hitting a very specific edge case.

1. You have two or more unnamed relations which are unambiguous.
2. Prisma autogenerates internal names for the relations. i.e. CollectionAutoCurationRuleToCollectionAutoCurationCondition and CollectionAutoCurationRuleToCollectionAutoCurationMatch
3. The names which are in the form Model1ToModel2 are longer than the db would allow for a table name.
4. Prisma shortens the name of relations to the maximum allowable length.
   CollectionAutoCurationRuleToCollectionAutoCuration
5. The shortened names end up being exactly the same for two different relations.
6. Prisma drops duplicates by relationName and then errors latter since an expected relation is missing.

I'll try to adjust our logic to produce a deploy error for that specific case asking you to name the relation.

[devautor]

@do4gr Why do I find this funny - because I did not have to debug it :D
BTW love the fix you are suggesting, thanks!

[Esya]

We're introspecting a quite big MySQL database and are facing the same issue, there are around 150 tables, and a whole load of relations - How can you find which one is causing the issue on prisma deploy ?

[ntziolis]

Same issue as @esya

[Raesta]

Same issue as @Esya & @ntziolis