id field is not of type string for model instead of ID
How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
v20.12.0
Amplify CLI Version
12.13.1
What operating system are you using?
Mac
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
No
Describe the bug
My schema has at least 30 days deployed without changes, today I going to change something however when I pushed the changes I got this issue:
InvalidDirectiveError: geofenceVehicleId field is not of type String
Schema line before the change:
geofenceVehicleId: ID! @index(name: "byGeofence", sortKeyFields: ["name"])
So I revert the change in my Schema but I'm still getting the same issue, after that I decided to change the type of the geofenceVehicleId for String, therefor I got the next error message:
InvalidDirectiveError: id field is not of type String
My Schema in this moment:
type Vehicle @model @auth(rules: [{ allow: public }]) {
id: ID!
}
I tried to change ID for String type and I can pushed the changes in a No-Prod environment and however I got this warning message:
This update will replace table(s) [VehicleTable]
ALL EXISTING DATA IN THESE TABLES WILL BE LOST!
If this is intended, rerun the command with '--allow-destructive-graphql-schema-updates'.
for that reason I cannot push the changes into my prod environment and I had to rollback all changes, and I still not have idea the reason why I got this error message.
I also want to highlight that this is the only one that gives me this error, while the other relationships are the same but do not have this particular issue.
Expected behavior
From my perspective, the schema should work as it did initially since I haven’t changed anything. However, I understand that a CLI update might have introduced changes, causing a new error like this. Ideally, the CLI should indicate what exactly I need to modify in my schema, specifying the exact line. Currently, it only mentions the attribute, and since I have many attributes with the same name, it’s difficult to pinpoint where the issue lies.
Reproduction steps
I suppose that the steps are related to the way how I setup the schema.
Project Identifier
Project Identifier: fb5b99268af59802a9999a876ab703cd
Log output
# Put your logs below this line
Additional information
No response
Before submitting, please confirm:
- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
- [X] I have removed any sensitive information from my code snippets and submission.
Hey @djom202, Thanks for raising this. Could you provide some additional details about the specific change made to the schema that resulted in this error?
Hi @AnilMaktala, the point is that I didn't change anything. I pushed some new changes when I got the error message. After that, I rolled back those changes, but the error message didn't disappear. Since it doesn't seem to be related to the changes, I believe it could be a new check in the CLI.
Hi @djom202, It seems like you pushed some changes, then you see the following error. After rolling back those changes, the following error still persist, is that correct? If so, could you share with us what's the changes that make the error first appear so we could have a bit more context?
InvalidDirectiveError: geofenceVehicleId field is not of type String
Yeah sure, I changed this:
type Vehicle @model @auth(rules: [{ allow: public }]) {
id: ID!
model_year: String!
....
}
by this:
type Vehicle @model @auth(rules: [{ allow: public }]) {
id: ID!
modelYear: String!
....
}
This error seems to come from part of the validation for @belongsTo @hasMany @hasOne directives. I don't see any field that uses these directives from the schema you provided. Just want to confirm, do you have any field that uses any of these directives?
InvalidDirectiveError: geofenceVehicleId field is not of type String
I am working to repro this issue, could you share with us which CLI version you were using when your schema was deployed successfully 30 days ago?
This is the Schema. And also I'm not sure if I can get the version I'm using in these moment however let me check.
I noticed that Vehicle uses plate (a String) as its primary key, not id. Geofence references Vehicle through geofenceVehicleId, which is of type ID!. The types (String vs. ID) don't match, thus causing the error:
InvalidDirectiveError: geofenceVehicleId field is not of type String
After setting id as the primary key in Vehicle, I am able to amplify push successfully. Let me know it this resolves the issue.
Ok it make senses. however I change the plate for ID I'm not sure if still can use the same values there, so what I'd like to know if it's possible to any KEY to be unique the PLATE field instead of primary key?
Sorry I am not sure I am following. Are you asking if it's possible to enforce uniqueness on a field like plate without making it the primary key?
Sorry I am not sure I am following. Are you asking if it's possible to enforce uniqueness on a field like
platewithout making it the primary key?
Yes
Unfortunately, we do not have any directive that enforces uniqueness at this moment.
This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.
Reopen this issue and mark it as a FR and also duplicate for enforcing uniqueness on non-primary key field. Existing FR for Unique Constraints: https://github.com/aws-amplify/amplify-category-api/issues/286