Data deleted via DataStore is still being returned in queries

[MarioCdeS]

Before opening, please confirm:

• I have searched for duplicate or closed issues and discussions.
• I have read the guide for submitting bug reports.
• I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.

JavaScript Framework

React Native

Amplify APIs

DataStore

Amplify Categories

storage, api

Environment information

  System:
    OS: Linux 6.2 Pop!_OS 22.04 LTS
    CPU: (12) x64 13th Gen Intel(R) Core(TM) i7-1365U
    Memory: 13.75 GB / 31.00 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.16.1 - ~/.nvm/versions/node/v18.16.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.16.1/bin/yarn
    npm: 9.5.1 - ~/.nvm/versions/node/v18.16.1/bin/npm
  Browsers:
    Brave Browser: 114.1.52.130
  npmPackages:
    @algolia/client-search: ^4.18.0 => 4.18.0 
    @algolia/transporter: ^4.18.0 => 4.18.0 
    @aws-amplify/cli-extensibility-helper: ^3.0.4 => 3.0.9 
    @aws-amplify/core: ^5.6.0 => 5.6.0 
    @aws-amplify/core/internals/aws-client-utils:  undefined ()
    @aws-amplify/core/internals/aws-client-utils/composers:  undefined ()
    @aws-amplify/core/internals/aws-clients/pinpoint:  undefined ()
    @aws-amplify/datastore: ^4.6.4 => 4.6.4 
    @aws-crypto/sha256-js: ^5.0.0 => 5.0.0 (1.2.2, 2.0.0, 3.0.0)
    @aws-sdk/client-location: ^3.370.0 => 3.370.0 (3.186.3)
    @aws-sdk/client-ses: ^3.370.0 => 3.370.0 
    @aws-sdk/client-sts: ^3.370.0 => 3.370.0 (3.186.3)
    @babel/core: ^7.17.9 => 7.21.3 
    @babel/preset-env: ^7.16.11 => 7.20.2 
    @babel/preset-typescript: ^7.16.7 => 7.21.0 
    @financiallease-nl/json-sort-ci: ^1.0.7 => 1.0.7 
    @react-native-async-storage/async-storage: ^1.19.0 => 1.19.0 
    @react-native-community/netinfo: ^9.4.1 => 9.4.1 
    @rollup/plugin-alias: ^3.1.9 => 3.1.9 
    @rollup/plugin-babel: ^5.3.1 => 5.3.1 
    @rollup/plugin-commonjs: ^21.0.3 => 21.1.0 
    @rollup/plugin-json: ^4.1.0 => 4.1.0 
    @rollup/plugin-multi-entry: ^4.1.0 => 4.1.0 
    @rollup/plugin-node-resolve: ^13.1.3 => 13.3.0 
    @rollup/plugin-typescript: ^8.3.1 => 8.5.0 
    @sentry/types: ^7.58.1 => 7.58.1 
    @types/amplify: ^1.1.25 => 1.1.25 
    @types/deep-equal: ^1.0.1 => 1.0.1 
    @types/jest: ^27.4.1 => 27.5.2 
    @types/jest-when: ^3.5.2 => 3.5.2 
    @types/node: ^17.0.30 => 17.0.45 (16.18.38)
    @typescript-eslint/eslint-plugin: ^5.35.1 => 5.56.0 
    @typescript-eslint/parser: ^5.18.0 => 5.56.0 
    algoliasearch: ^4.18.0 => 4.18.0 
    aws-amplify: ^5.3.4 => 5.3.4 
    aws-amplify-react-native: ^7.0.2 => 7.0.2 
    aws-sdk-client-mock: ^2.1.1 => 2.1.1 
    babel-jest: ^28.0.3 => 28.1.3 (27.5.1)
    babel-plugin-module-resolver: ^5.0.0 => 5.0.0 
    base64-js: ^1.5.1 => 1.5.1 
    deep-equal: ^2.2.2 => 2.2.2 
    eslint: ^8.12.0 => 8.36.0 
    eslint-config-prettier: ^8.5.0 => 8.8.0 
    eslint-import-resolver-alias: ^1.1.2 => 1.1.2 
    eslint-plugin-i18n-json: ^4.0.0 => 4.0.0 
    eslint-plugin-jsdoc: ^39.2.9 => 39.9.1 
    eslint-plugin-json: ^3.1.0 => 3.1.0 
    eslint-plugin-json-format: ^2.0.1 => 2.0.1 
    eslint-plugin-react: ^7.29.4 => 7.32.2 
    eslint-plugin-sort-exports: ^0.6.0 => 0.6.0 
    esm: ^3.2.25 => 3.2.25 
    fetch-mock: ^9.11.0 => 9.11.0 
    fuse.js: ^6.6.2 => 6.6.2 
    isomorphic-unfetch: ^4.0.2 => 4.0.2 (3.1.0)
    jest: ^27.5.1 => 27.5.1 
    jest-junit: ^13.2.0 => 13.2.0 
    jest-when: ^3.5.1 => 3.5.2 
    jsdoc: ^4.0.2 => 4.0.2 
    mustache: ^4.2.0 => 4.2.0 
    nodemon: ^2.0.20 => 2.0.22 
    prettier: ^2.7.1 => 2.8.6 
    rimraf: ^3.0.2 => 3.0.2 (2.6.3, 2.2.8)
    rollup: ^2.70.1 => 2.79.1 
    rollup-plugin-dts: ^4.2.2 => 4.2.3 
    rollup-plugin-terser: ^7.0.2 => 7.0.2 
    ts-node: ^10.7.0 => 10.9.1 
    tsconfig-paths: ^3.14.1 => 3.14.2 
    tslib: ^2.3.1 => 2.5.0 (1.14.1, 2.6.0)
    typedoc: ^0.23.24 => 0.23.28 
    typedoc-plugin-extras: ^2.3.2 => 2.3.2 
    typedoc-theme-hierarchy: ^3.0.2 => 3.1.0 
    typescript: ^4.6.3 => 4.9.5 (5.0.2, 4.4.4)
    uuid: ^9.0.0 => 9.0.0 (8.3.2, 3.4.0)
    zod: ^3.21.4 => 3.21.4 
  npmGlobalPackages:
    @aws-amplify/cli: 12.1.1
    corepack: 0.17.0
    eas-cli: 3.15.1
    npm: 9.5.1
    yarn: 1.22.19

Describe the bug

I am experiencing a weird issue where data, that was previously deleted, is reappearing in query results. The client deletes items via DataStore.delete(). Examining the DynamoDB table, the items have been flagged as deleted. The delta table reflects the same. The client is set up to observe mutations on the related model, and it does receive the resulting DELETE messages. At this point, any subsequent queries on the model behave as expected i.e. the deleted items are not returned. I only experience problems once I restart the client app.

After restarting, the previously deleted items are now returned in the query results. The items are still flagged as deleted in the DynamoDB table, so the issue is with the local cache. Clearing the cache (DataStore.clear()) fixes the issue, however, this isn't a viable solution.

I noticed that there was a similar issue reported previously, though it doesn't seem to have been resolved: aws-amplify/amplify-cli#1868

Any pointers or advice on how to resolve this problem would be greatly appreciated.

Expected behavior

Deleted items should remain deleted on client.

Reproduction steps

1. Delete item via DataStore.
2. Restart client application.
3. Perform query that would have returned previously deleted item.

Code Snippet

// Put your code below this line.

Log output

// Put your logs below this line

aws-exports.js

No response

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

[AnilMaktala]

Hi @MarioCdeS 👋, Thanks for raising this issue.we are working on reproducing the issue. Could you please run below command and send us the report.
amplify diagnose --send-report.
please refer here

[MarioCdeS]

Hey, @AnilMaktala.

Thanks very much for assisting. The report archive has been uploaded. The PI is 1ec424ae6419fc281983cb7d68b43bc1.

[svidgen]

@MarioCdeS Are you seeing any errors or warnings in the browser console when this occurs? Whether at the time you delete the records, after restarting the app, or when clearing DataStore and then restarting?

If you can consistently reproduce this, please try doing a repro with the network tab open and recording — see if you can spot any graphql errors or mutations occurring at unexpected times, like after you'd expect DataStore to already be "ready". On that note, can you confirm that DataStore has emitted its ready event prior to your interactions with the data?

Information about the ready event is here: https://docs.amplify.aws/lib/datastore/datastore-events/q/platform/js/#ready

If you can share any app code representing a minimal reproduction, that would be very helpful too.

[chrisbonifacio]

@MarioCdeS can you please confirm some of the details so we can better investigate this? We're curious to see if, when calling DataStore.delete, the records are being removed from the local store or not.

[MarioCdeS]

Hi, @svidgen / @chrisbonifacio.

There are no errors generated when deleting the record for the first time, nor when restarting the app, nor clearing DataStore.

On startup, the client application waits for the DataStore ready event before proceeding with any queries. Examining the network traffic reveals no unexpected GraphGL mutations nor errors.

If I attempt to delete the "phantom" record, the delete mutation fails with ConflictUnhandled: Conflict resolver rejects mutation.

I, unfortunately, do not have any code that I can share right now. Below is a sequence diagram of events during repro, if it helps at all.

[CristianGrosu2022]

Any updates on this? I am facing the same issue

[chrisbonifacio]

@MarioCdeS I haven't been able to reproduce this on the latest version of aws-amplify.

@CristianGrosu2022 @MarioCdeS Can you both let us know what conflict resolution strategy you might have configured? (Auto Merge, Optimistic Concurrency, etc)

@CristianGrosu2022 What version of aws-amplify are you using? Also, if you have any code snippets of how you're deleting records or reproduction steps for how you're running into the issue, please share!

When the ERR: Conflict resolver rejects mutation part occurs, are there any outgoing mutations in the network activity? If so, what is the version number that was sent? Looks like the first mutation returned an incremented version for the record, but the version of the record on the server did not change.

This would suggest that the delete update mutation never actually succeeded. This behavior sounds like optimistic concurrency to me but I'd like to confirm.

[chrisbonifacio]

Hi 👋 Closing this as we have not heard back from you. If you are still experiencing this issue and in need of assistance, please feel free to comment and provide us with any information previously requested by our team members so we can re-open this issue and be better able to assist you.

Thank you!

[Makatun]

Facing same issue

[AnilKumar835]

Experiencing the same issue:

In both offline and online modes, I perform the following actions:

Create a single item
Update the created item
Delete the item
When I directly check the DynamoDB table, I observe that the item's _version is correctly incremented to 3, and _deleted is set to true. This signifies the three actions (create, update, delete).

After the deletion, the response from the app confirms the deletion, and subsequent queries do not show the deleted item, which is the expected behavior.

However, the problem arises when I kill the application and restart it. Upon returning, the deleted item reappears. Upon inspecting the deleted record, I notice that it returns with a _version less than the last updated version.

In cases where I always receive _deleted: null when restarting the app, the deleted item is correctly not displayed.

I want to highlight that there are no errors reported during the delete action or when restarting the application. For the delete operation, I'm using the following query:

DataStore.delete(TableName, id);
If anyone has encountered a similar issue or has suggestions on how to address this, I would greatly appreciate your insights and assistance.

Thank you!

[simplypixi]

Experiencing the same issue:

In both offline and online modes, I perform the following actions:

Create a single item Update the created item Delete the item When I directly check the DynamoDB table, I observe that the item's _version is correctly incremented to 3, and _deleted is set to true. This signifies the three actions (create, update, delete).

After the deletion, the response from the app confirms the deletion, and subsequent queries do not show the deleted item, which is the expected behavior.

However, the problem arises when I kill the application and restart it. Upon returning, the deleted item reappears. Upon inspecting the deleted record, I notice that it returns with a _version less than the last updated version.

In cases where I always receive _deleted: null when restarting the app, the deleted item is correctly not displayed.

I want to highlight that there are no errors reported during the delete action or when restarting the application. For the delete operation, I'm using the following query:

DataStore.delete(TableName, id); If anyone has encountered a similar issue or has suggestions on how to address this, I would greatly appreciate your insights and assistance.

Thank you!

Same issue here. Did you resolve the problem?