mhyassin
commented
1 year ago So I tried removing the syncExpressions it definitely fixed the issue, but that will result in scans on the base sync
Open mhyassin opened 1 year ago
mhyassin
commented
1 year ago So I tried removing the syncExpressions it definitely fixed the issue, but that will result in scans on the base sync
mhyassin
commented
1 year ago {"limit":1000,"nextToken":null,"lastSync":0,"filter":{"and":[{"user_name":{"eq":"XXX"}}]}}Trying a query those vars on the delta table from the console fails as well, removing the and fixes it, we don't know why it fails though with the and operator, removing the syncExpressions fixed it because it dropped the vars
iartemiev
commented
1 year ago Removing the and from the filter expression should result in a Scan operation. The and is necessary for the generated resolver to map the filter to an index/key condition correctly.
When you execute the sync query in the AppSync Console with the arguments in your last comment, what error do you get back?
mhyassin
commented
1 year ago @iartemiev
Oh interesting, that's the error on the AppSync Console
Query condition missed key schema element: ds_pk (Service: DynamoDb, Status Code: 400,
iartemiev
commented
1 year ago That error suggests DynamoDB is not receiving the expected key condition when performing the query.
I tried to reproduce this with the schema you shared in this comment. But everything seems to work as expected.
Could you enable logs on your AppSync API by going to Settings > API configurations > Edit. Select these options:
Click Save.
Go back to Queries in the Console, check the Logs checkbox in the bottom right and perform another sync query with the same arguments.
After the query executes, click the "View in Cloudwatch" link. Once the CloudWatch console opens up, filter the log events on RequestMapping syncScores
Expand the most recent log event (by timestamp) that matches that filter. Then inspect the transformedTemplate property. Please paste it here, redacting any sensitive information if present.
It should look similar to this:
mhyassin
commented
1 year ago Hey @iartemiev, thanks a lot for looking this further it is very important for us as it is causing us a lot of production issues right now.
Right now I can't actually replicate the issue for the scores table with my user at least, it seems to be random somehow, we have 9 models in total, sometimes it can be reproduced on 7 or 8 of them, now I can only reproduce it on only one (on this specific environment at least)
The model I'm currently testing with looks like this:
type CoachMessage
@model
@auth(
rules: [
{
allow: owner
operations: [read, update, create]
identityClaim: "username" # explicit use of username
ownerField: "user_name"
}
]
) {
user_name: String! @primaryKey(sortKeyFields: ["id"])
id: String!
reply_to: String
datetime: AWSDateTime!
type: CoachMessageType!
role: CoachMessageRole!
content: String!
followup_questions: [String!]
data: String
}I've did some queries in order to let you know exactly what fails:
With lastsync set to 0
With last sync set to timestamp older than 30 minutes (Delta ttl)
With lastsync set to timestamp not older than 30 minutes (Delta ttl)
This is how the transformTemplate looks like for the last query
"transformedTemplate": " {\"version\":\"2018-05-29\",\"operation\":\"Sync\",\"limit\":1000,\"lastSync\":1691842203749,\"query\":{\"expression\":\"#pk = :pk\",\"expressionNames\":{\"#pk\":\"user_name\"},\"expressionValues\":{\":pk\":{\"S\":\"236448d2-9001-7036-bbec-0234424b9b3d\"}}},\"scanIndexForward\":true}\n"I verified with the team that manages the Amplify GraphQL Transformer (https://github.com/aws-amplify/amplify-category-api/) that there is a limitation that prevents us from performing a Query operation against the Delta table when using a custom PK.
Overall, we don't recommend using the owner field as the primary key (see grey call out in this section of the docs https://docs.amplify.aws/cli/graphql/authorization-rules/#per-user--owner-based-data-access)
I suggest changing your data model to use a separate primary key field and then creating a GSI using the @index directive on your owner field. That'll allow you to use that field in your selective sync expression successfully.
I'll transfer this issue to the category-api repo
mhyassin
commented
1 year ago @iartemiev Thanks a lot for the help!
May you elaborate more on why is it not recommended to use the the owner field as the primary key? is it only because of that delta table issue? or is there something else?
So if that PR you mentioned gets merged, would it then be possible to use the owner field as a primary key? creating another index would double our storage pricing
Before opening, please confirm:
JavaScript Framework
React Native
Amplify APIs
Authentication, Analytics, GraphQL API, DataStore, Storage
Amplify Categories
No response
Environment information
Describe the bug
Our DataStore's initial sync is kind of fast, but after that every time I close the app and re opens (should trigger delta sync) the
readyevent takes too much time to be sent, while debugging Amplify I saw a lot of these errorsI noticed that they are being logged after trying to execute the sync queries(7 out of 9 models, the other 2 are syncing quite fine), they keep being attempted 12 times, after the 12th attempt this is logged:
I researched for the
User is unauthorizedissue and the fix in aws-amplify/amplify-js#9179 isn't working, and there are noUnauthorizedExceptionin the appsync logsSince the
readyevent is taking forever to be sent the outbox doesn't get synced at all, till all the 12 attempts are done Project identifier: 1f41c9d6304e82061193f8ee2e85ae0aExpected behavior
User should be authorized to sync queries
Reproduction steps
@authmodelsCode Snippet
Log output
aws-exports.js
Manual configuration
No response
Additional configuration
No response
Mobile Device
No response
Mobile Operating System
No response
Mobile Browser
No response
Mobile Browser Version
No response
Additional information and screenshots
No response