-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(DataStore): dataStore cannot connect to model's sync subscriptions (AWS_LAMBDA auth type) #3550
base: main
Are you sure you want to change the base?
fix(DataStore): dataStore cannot connect to model's sync subscriptions (AWS_LAMBDA auth type) #3550
Conversation
…s (AWS_LAMBDA auth type) aws-amplify#3549
Hi @MuniekMg, thanks for opening this PR. I believe some AppSync backends were provisioned without the Most likely we will have to introduce a new configuration property on |
Hi @lawmicha,
I have added DataStoreConfiguration.subscriptionFiltering in the last commit. What do you think? [EDIT] |
@MuniekMg, I editted my message to mention i'll check with the team, maybe you missed it since I had editted sometime later, sorry for the extra work! I was able to check with the team and found out the approach that Amplify JS library is taking.
I think the approach of adding a new configuration flag will require documentation and developers to know about it. This feature was launched in April 2022 so all new customers would have to set the flag which would be a pretty poor DX. Retrying without the filter for the customers with the old provisioning appears to be the performance trade-off we are willing to make. |
8fa7fed
to
b96fbda
Compare
…s (AWS_LAMBDA auth type) aws-amplify#3549
@lawmicha I have removed my last commit and created a new one with a possible solution (work in progress) for retrying subscription requests (e.g. without a filter), but it looks a little messy, and I'm not sure whether I should continue this approach. (commit e70a3f5) |
Sorry for the delay, we're working on migrating the |
} | ||
|
||
// TODO: - How to distinguish errors? | ||
// TODO: - Handle other errors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like there is a whole list of errors to catch based on the strings https://github.com/aws-amplify/amplify-js/blob/main/packages/datastore/src/sync/processors/subscription.ts#L692-L698
|
||
// Just to be sure that endless retry won't happen | ||
filterLimitRetried = true | ||
maxRetries += 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is maxRetries
updated here to account for the attempt
being incremented for the RTF retry case? So the overall attempt
to maxRetries
counts will continue to represent the number of auth types to attempt? (maxRetries is set to the number of auth types to attempt in multi-auth rules scenarios).
…s (AWS_LAMBDA auth type) aws-amplify#3549
@lawmicha No problem :) I have just finished implementing the same logic like in JS implementation (reconnecting in case of any RTF error) and added more tests (commit e0398e4). It would be great if You could merge those changes while waiting for your new implementation. |
Bug: #3549
General Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.