[Introspection] Panic "No id field defined!" (caused by: no id at all)

[janpio]

• Error: Schema parsing thread 'main' panicked at 'No id field defined!', src\libcore\option.rs:1190:5
• panic-no-id-field-defined

---

Introspection failed: Introspected schema can't be parsed.
Error: Schema parsing thread 'main' panicked at 'No id field defined!', src\libcore\option.rs:1190:5
stack backtrace:
   0: backtrace::backtrace::dbghelp::trace
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.37\src\backtrace/dbghelp.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\github.com-1ecc6299db9ec823\backtrace-0.3.37\src\backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src\libstd\sys_common/backtrace.rs:76
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src\libstd\sys_common/backtrace.rs:60
   4: core::fmt::write
             at src\libcore\fmt/mod.rs:1030
   5: std::io::Write::write_fmt
             at src\libstd\io/mod.rs:1412
   6: std::sys_common::backtrace::_print
             at src\libstd\sys_common/backtrace.rs:64
   7: std::sys_common::backtrace::print
             at src\libstd\sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src\libstd/panicking.rs:196
   9: std::panicking::default_hook
             at src\libstd/panicking.rs:210
  10: std::panicking::rust_panic_with_hook
             at src\libstd/panicking.rs:473
  11: std::panicking::continue_panic_fmt
             at src\libstd/panicking.rs:380
  12: rust_begin_unwind
             at src\libstd/panicking.rs:307
  13: core::panicking::panic_fmt
             at src\libcore/panicking.rs:85
  14: core::option::expect_failed
             at src\libcore/option.rs:1190
  15: once_cell::imp::OnceCell<T>::initialize::{{closure}}
  16: once_cell::imp::initialize_inner
  17: once_cell::imp::OnceCell<T>::initialize
  18: prisma_models::fields::Fields::id
  19: query_core::schema_builder::object_type_builder::ObjectTypeBuilder::many_records_arguments
  20: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
  21: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::next
  22: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
  23: query_core::schema_builder::object_type_builder::ObjectTypeBuilder::new
  24: query_core::schema_builder::query_schema_builder::QuerySchemaBuilder::new
  25: prisma::cli::CliCommand::execute
  26: <std::future::GenFuture<T> as core::future::future::Future>::poll
  27: tokio_executor::enter::Enter::block_on
  28: std::thread::local::LocalKey<T>::with
  29: tokio::runtime::threadpool::Runtime::block_on
  30: prisma::main
  31: std::rt::lang_start::{{closure}}
  32: std::rt::lang_start_internal::{{closure}}
             at src\libstd/rt.rs:49
  33: std::panicking::try::do_call
             at src\libstd/panicking.rs:292
  34: __rust_maybe_catch_panic
             at src\libpanic_unwind/lib.rs:80
  35: std::panicking::try
             at src\libstd/panicking.rs:271
  36: std::panic::catch_unwind
             at src\libstd/panic.rs:394
  37: std::rt::lang_start_internal
             at src\libstd/rt.rs:48
  38: main
  39: _tmainCRTStartup
  40: mainCRTStartup
  41: sqlite3GenerateConstraintChecks
  42: sqlite3GenerateConstraintChecks
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
    at Object.<anonymous> (C:\ProgramData\nvm\v10.16.3\node_modules\prisma2\build\index.js:70179:23)
    at Generator.throw (<anonymous>)
    at rejected (C:\ProgramData\nvm\v10.16.3\node_modules\prisma2\build\index.js:70074:65)
    at process._tickCallback (internal/process/next_tick.js:68:7)

probably caused by

model oseba {
  alkotest                    Float?
  alkotest_d                  String
  drzavljanstvo               String
  id_nesreca                  nesreca
  poskodba                    String?       @default("NULL")
  povzrocitelj_ali_udelezenec String?       @default("NULL")
  spol                        String
  starost                     Boolean?
  starost_d                   String?       @default("NULL")
  strokovni_pregled           Float?
  strokovni_pregled_d         String
  upravna_enota               upravna_enota
  varnostni_pas_ali_celada    String?       @default("NULL")
  vozniski_staz_d             String
  vozniski_staz_LL            Boolean?
  vozniski_staz_MM            Boolean?
  vrsta_udelezenca            String?       @default("NULL")
}

source: https://github.com/prisma/introspection-engine-output/blob/master/more_mysql/Accidents.log

possible explanation:

• no primary key defined
• no unique field at all

[sorenbs]

Decision

We have no Guardrails for this, so we will hope for the feature to be implemented in time.

[janpio]

Collection of schemas where the complete absence of an @id or @@id was confirmed as the source of the panic (via adding a foo Int @id):

https://github.com/prisma/introspection-engine-output/blob/master/mysql_127/Accidents.log

This is the only (!) schema where the absence of @id or @@id caused a panic - all others are already failing during validation, which is tracked in: #1083

[janpio]

Which leads to the real question:
Why does this not fail in validation already?

[janpio]

Seems the validation does not trigger because the schema could essentially be rewritten as:

model foo {
  i    Int   @id
  bars bar[]
}

model bar {
  i   Int
  foo foo
  baz baz
}

model baz {
  i    Int   @id
  bars bar[]
}

As soon as foo or baz are removed from bar, the validation triggers.

Is this a validation bug?

[janpio]

Investigating and fixing other schemas lead to discovery of more such cases:

model affiliations_documents {
  affiliation_id affiliations
  document_id    documents    @relation(references: [id])
}

model affiliations_events {
  affiliation_id affiliations
  event_id       events       @relation(references: [id])
}

model affiliations_media {
  affiliation_id affiliations
  media_id       media        @relation(references: [id])
}

[...]

https://github.com/prisma/introspection-engine-output/blob/master/postgres/sportsdb.log

These also pass validation with their relations, and then cause a panic later.

[janpio]

Question: Does it make sense that it does not fail in the validation step already?

If not, we should add that (and by doing so give us an opportunity to educate the user about workaround (fix table, remove table from introspection) and thus avoid this panic.

[janpio]

Internal Note: See #1515

[do4gr]

These cases will now give a validation error asking for an Id to be added. See explanation here: #1515