@restore truncating the global ID for the returned data
Describe the bug
When a model has the @softDeletes directive set and you attempt to restore the model as follows:
mutation restore ($id: ID!) {
restoreModel (id: $id) {
id
deleted_at
}
}
The returned data package is truncating the last 4 characters of the id.
This means that whilst the mutation was successful (confirmed that the data in the DB is being correctly changed), the apollo cache is unable to update itself because the id does not exist.
Expected behavior/Solution
The restore mutation should return the full global id for the item, and not truncate the last 4 characters.
Steps to reproduce
- Run a delete mutation:
mutation delete ($id: ID!) {
deleteModel (id: $id) {
id
deleted_at
}
}
- Run a restore mutation for the same ID:
mutation restore ($id: ID!) {
restoreModel (id: $id) {
id
deleted_at
}
}
Lighthouse Version v5.6.0
Sorry all, this seems to be an issue with my schema file.
I originally had:
restoreModel(id: ID! @globalId @rules(apply: ["required"])): Model
@restore(model: "App\\Models\\Model")
When I should have had:
restoreModel(id: ID! @rules(apply: ["required"])): Model
@restore(globalId: true, model: "App\\Models\\Model")
Think there's a statement in the documentation about the globalId: true being deprecated, and you should use the @globalId variant in V6+. I clearly took this as being that both methods work in v5, but I guess this is incorrect - perhaps someone else can confirm this?
The @globalId variant should work, I am looking into this.
@spawnia thanks for looking into this.
The issue is the same if you use the @globalId on a delete mutation too. I originally had the delete with the globalId: true defined and the restore with the @globalId.
i.e.
deleteSomeModel(
id: ID! @globalId @rules(apply: ["required"])
): SomeModel @delete(model: "App\\Models\\Some\\Model")
When you run the mutation as follows:
mutation delete ($id: ID!) {
deleteSomeModel (id: $id) {
id
deleted_at
}
}
It drops the last 4 characters of the returned ID too. I assume this is because the directive is the same and that's where the issue is. Either that or it's to do with the mutation code - those seem to be the only two common parts.
To confirm my type definition looks like this:
type SomeModel @node(model: "App\\Models\\Some\\Model") {
id: ID! @globalId
_id: ID! @rename(attribute: "id")
telephone: String
parent: MyParent! @belongsTo
address: Address! @hasOne
created_at: DateTimeUtc!
updated_at: DateTimeUtc!
deleted_at: DateTimeUtc
}
Just in case it's something in the definition of the schema.
Let me know if you need any more information from me on this one - happy to help.
Closing due to lack of a reproducible test case. Feel free to add a pull request that adds a missing test.