Inconsistent state when using task actions
Closed this issue · 3 comments
Cypress test in cypress/integration/actions_spec.js consistently puts the task into an inconsistent state with the task status not matching what is expected.
This issue can also be reproduced manually when using the app on a low powered device like a smartphone.
The test runs through the sequence of assigning a rider, setting the picked up time, delivered time and rider home time. The state of the task at the end of the test should be completed with the three times set.
Dashboard instead shows the task in the delivered column. When opening the dashboard in another browser, the task may be in delivered or any other column in the in progress tab, often with some of the times set and some not. Sometimes the TaskActions component reverts to old state after the test has completed.
Apart from the local data in the test browser not being correct, DataStore appears to not sync data properly to other devices. Sometimes after the test has run, DataStore stops syncing any new data even when interacting with the task overview. Actual queries made to appsync can be verified by looking at the network tab in dev tools. seems to be better with commit 4bf14c8
Unit tests for the TaskActions component verify that the correct data is being saved with DataStore.save and in the correct order.
The TaskActions component uses a DataStore.observe subscription to prevent the user from setting the next time in the sequence before the previous time is saved.
The TaskActions component also responds slowly to input when using on a low powered device like a smartphone, but seems to be fine while on a desktop PC or when used in the demo build.
Using the mouse hover context menu instead of the TaskActions component seems to be less problematic.
Steps to reproduce:
-
run the actions_spec.js test in Cypress
-
load the page in a smartphone browser
-
quickly set or unset times in the actions component
Expected behaviour:
The status of the task should match what is expected based on progress of the job. Active for assigned tasks, picked up, delivered and completed for rider home. Any times set should also persist and not unset itself. Data should be synchronised between all devices.
Some new information I've found after digging more.
- the _version of the record stays at 1 throughout each update
- querying the model returns version 1 even when the record has been updated multiple times
- DataStore is attempting to make mutations to the backend with the _version set as 1 as well (and it says the mutation is successful)
- if I add a 1 second delay between each action in cypress, the backend catches up quickly enough for the version to increment. in this case the data in the backend actually matches what is being saved
- however despite _version being 1 in mutations, the record does get partially updated in dynamodb from its first version, the data is just inconsistent (some fields are updated, some aren't)
With conflict resolution enabled, Amplfiy requires _version to be sent with each graphql request and to match the current record.
Unfortunately I was pre-emptive because I thought a good fix would be to wait until _version changed before enabling the next step. This does work in both Cypress and while using mobile (but mobile is still very slow).
However I realised this means that offline is no longer supported because it's relying on an internet connection to retrieve the incremented _version.
Some progress but still not fixed.
EDIT: pushed master back and made a new branch with my sort of fix - taskactions_fix
Amplify have acknowledged this is an issue with DataStore, tracked with issue #9979 on amplify-js.