Skip to content
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

Inconsistent store #43

Merged
merged 10 commits into from
Feb 27, 2018
Merged

Inconsistent store #43

merged 10 commits into from
Feb 27, 2018

Conversation

onlybakam
Copy link
Contributor

Fix issue with missing update function and an inconsistent appsync store

onlybakam and others added 5 commits February 7, 2018 22:46
…c-sdk-js

* 'master' of https://github.com/awslabs/aws-mobile-appsync-sdk-js:
  Release aws-appsync@1.0.10
  Update CHANGELOG.md
  Update x-amz-user-agent header
  Release aws-appsync@1.0.9
  Preserve the observer associated with an existing topic (#37)
  Fix AWS_IAM credentials fetching (#38)
for effect

When calling `enqueueMutation` in `offline-link.js`, the operation
object created by `QueryManager` does not contain the update function.
See `buildOperationForLink`. To preserve the update function, we save it
in `AASContext` which is included (in `context`) when building the
operation
Constantly restoring apollo cache from store after writing causes issues
with optimistic responses. The patches are not pruned and ultimately the
appsync store does not end up with the correct data and the apollo cache
is 'corrupted'. Easily reproducible by creating a mutation with a
pessimistic boolean flag on optimistic response, no update function (as
to not update an existing query) and no running subscription.
onlybakam and others added 3 commits February 14, 2018 00:14
The problem actually occurs when we execute recordOptimisticTransaction.
During an optimistic transaction on the offline-cache, the data object
that backs up the cache is swapped with a recordingCache. This object is
responsible for recording the data diff for the optimistic transaction.
So the optimistic results are written to the recordingCache which keeps
a data and recordedData set (the calculated diff). Currently after the
write, the offline-cache then extracts all the data (from the data set)
and sends it to the redux store. Our subscription is triggered and we
call replace with the new data which calls restore on the
recordingCache. So this is where the actual “corruption” happens.
recordedData is returned as the patch, the transaction ends and the
recordingCache is replaced by the original ObjectCache object. When our
mutation result is returned from the server and we call extract to save
it to the redux store we get the data + the patch.
@manueliglesias manueliglesias self-requested a review February 27, 2018 01:19
Copy link
Contributor

@manueliglesias manueliglesias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 LGTM 🎉

@manueliglesias manueliglesias merged commit d26ea1c into awslabs:master Feb 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants