amplify-codegen
amplify-codegen copied to clipboard
Querying multiple top-level fields only returns the the first one
Before opening, please confirm:
- [X] I have installed the latest version of the Amplify CLI (see above), and confirmed that the issue still persists.
- [X] I have searched for duplicate or closed issues.
- [X] I have read the guide for submitting bug reports.
- [X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
How did you install the Amplify CLI?
npm
If applicable, what version of Node.js are you using?
v16.13.1
Amplify CLI Version
7.6.23
What operating system are you using?
Mac OS
Amplify Codegen Command
codegen, codegen types
Describe the bug
Amplify generates types (API service in case of angular) which automatically returns first top-level field from the operation. When querying multiple top-level fields in one operation with custom query only the first one is returned.
query Sessions($userId: ID!, $now: String!) {
upcoming: sessionsByUser(userID: $userId, startTime: { ge: $now }, sortDirection: ASC) {
items { ... }
nextToken
}
past: sessionsByUser(userID: $userId, startTime: { lt: $now }, sortDirection: DESC) {
items { ... }
nextToken
}
// api.service.ts
async Sessions(userId: string, now: string): Promise<SessionsQuery> {
// ...
return <SessionsQuery>response.data.upcoming;
}
Expected behavior
Generated method should return the whole data object if there's more than one top-level field.
return <SessionsQuery>response.data;
and also SessionQuery type should contain definition for those two connections, not just one ModelSessionConnection.
Reproduction steps
- Create custom query that will query multiple top-level fields (either different or same ones using alias)
- Run
amplify codegen types - Observe what has Amplify generated in configured
generatedFileNamelocation
GraphQL schema(s)
# Put schemas below this line
Log output
# Put your logs below this line
Additional information
No response
Hi @vojtech-simko. Thanks for bring this to our attention. We need few more details to effectively reproduce this.
- Can you please share the part of your schema with the custom Query definition?
- What is the current behavior when you try to access
<SessionsQuery>response.data.pastfield?
In schema I'm defining this model (not the query). The custom query uses sessionsByUser query defined in byUserAndStartTime index on startTime field.
type Session
@model(subscriptions: null)
@auth(
rules: [
{ allow: owner, ownerField: "userID" }
{ allow: private, operations: [read] }
{ allow: public, operations: [read], provider: iam }
]
)
@searchable {
bookings: [Booking] @hasMany(indexName: "bySession", fields: ["id"])
bookingsCount: Int @default(value: "0")
draft: Boolean
duration: Int!
id: ID! @primaryKey
name: String!
startTime: AWSDateTime!
@index(name: "byStartTime", queryField: "sessionsByStartTime")
tags: String
userID: ID!
@index(
name: "byUserAndStartTime"
queryField: "sessionsByUser"
sortKeyFields: ["startTime"]
)
createdAt: AWSDateTime!
updatedAt: AWSDateTime!
}
then I have the custom query in src/graphql/session/Query.getSessions.gql
I can't access <SessionsQuery>response.data.past because the auto-generated angular service (api.service.ts in my case) returns only <SessionsQuery>response.data.upcoming. However if I manually change it to past or return the whole response.data object it contains the past connection.
"data": {
"upcoming": {
"__typename": "ModelSessionConnection",
"items": [ ],
"nextToken": null
},
"past": {
"__typename": "ModelSessionConnection",
"items": [ ],
"nextToken": null
}
}
Thanks for the additional information. We are looking into a fix now.
As a workaround for now you can use two custom queries.
query PastSessions($userId: ID!, $now: String!) {
past: sessionsByUser(userID: $userId, startTime: { lt: $now }, sortDirection: DESC) {
items { ... }
nextToken
}
}
query UpcomingSessions($userId: ID!, $now: String!) {
upcoming: sessionsByUser(userID: $userId, startTime: { ge: $now }, sortDirection: ASC) {
items { ... }
nextToken
}
}
Yep, doing that until a fix is provided. I'd be nice to load both queries with one request 🤞