The Relay Resolver backing this field is defined with an invalid `fragment_name`

[pnispel]

Experimenting with resolvers, I'm not sure if this is a bug or I'm doing something wrong.

With a type straight out of the documentation like:

type PetModel = {
  id: DataID
}

/**
 * @RelayResolver Pet
 */
export function Pet(id: DataID): PetModel {
  return null
}

I get the following error:

[ERROR] Error: ✖︎ The Relay Resolver backing this field is defined with an invalid `fragment_name`. Could not find a fragment named 'Pet__id'.

  src/schema-extensions/resolvers/pet.ts:16:3
   16 │ *
      │ ^
   17 │  * @RelayResolver Pet

I'm not sure what this means or how to fix it. Heres my config: v18.2.0

"relay": {
    "noFutureProofEnums": true,
    "typescriptExcludeUndefinedFromNullableUnion": true,
    "artifactDirectory": "./src/__generated__/",
    "customScalarTypes": {
      "UUID": "string",
      "BigInt": "string",
      "NativeBigInt": "bigint",
      "Date": "string",
      "JSON": "JSONType",
      "Datetime": "string",
      "Upload": "File"
    },
    "language": "typescript",
    "schema": "./../types/schema.graphql",
    "src": "./src/",
    "schemaConfig": {
      "nodeInterfaceIdField": "nodeId"
    },
    "schemaExtensions": [
      "./src/schema-extensions"
    ]
  }

[pnispel]

Seems like it has to do with

"schemaConfig": {
      "nodeInterfaceIdField": "nodeId"
    },

[pnispel]

Can confirm with a local build that this diff fixes the immediate issue, not sure about the fallout:

--- a/compiler/crates/docblock-shared/src/lib.rs
+++ b/compiler/crates/docblock-shared/src/lib.rs
@@ -158,7 +158,7 @@ lazy_static! {
     /// Field name used for the ID of strong model types.
     /// Note: this should **only** be used for resolvers! The id field for server
     /// types is configurable in the config, and thus cannot be hard-coded.
-    pub static ref KEY_RESOLVER_ID_FIELD: StringKey = "id".intern();
+    pub static ref KEY_RESOLVER_ID_FIELD: StringKey = "nodeId".intern();

[robertf224]

do we have any idea when this fix is landing?

[captbaritone]

Looks like @pnispel closed their PR. Would someone like to open a PR to use the compiler config value for the id field here? It would probably be worth an audit to see if there are other places where we are hard coded to the field being id.

[robertf224]

oh I see I thought that meant it had merged into the private upstream repo. the PR almost worked, I built the fork locally and it let me build the resolvers but the generated code was still a bit broken (some imports had an extra "_")