Clarification / Implementation: Conflict Resolution, Transactions, and Batch Writes

[jmarshall9120]

Is this related to a new or existing framework?

No response

Is this related to a new or existing API?

REST API, GraphQL API, DataStore

Is this related to another service?

appsync, dynamodb

Describe the feature you'd like to request

There doesn't seem to be any direct documentation listing the lack of support for transactions and batch writes when conflict resolution is enabled. I have attempted to write resolvers for each and I end up getting these errors:

{
  "data": {
    "BatchInsertCompanySingleTable": null
  },
  "errors": [
    {
      "path": [
        "BatchInsertCompanySingleTable"
      ],
      "data": null,
      "errorType": "MappingTemplate",
      "errorInfo": null,
      "locations": [
        {
          "line": 2,
          "column": 3,
          "sourceName": null
        }
      ],
      "message": "Unsupported operation 'TransactWriteItems'."
    }
  ]
}

{
  "data": {
    "BatchInsertCompanySingleTable": null
  },
  "errors": [
    {
      "path": [
        "BatchInsertCompanySingleTable"
      ],
      "data": null,
      "errorType": "MappingTemplate",
      "errorInfo": null,
      "locations": [
        {
          "line": 2,
          "column": 3,
          "sourceName": null
        }
      ],
      "message": "Unsupported operation 'BatchPutItem'."
    }
  ]
}

An unfortunate circumstance to spend hours researching and implementing just to dead end on an error. I suggest the docs be made more clear on this issue.

I searched the docs for hours. The most relevant articles, that I feel should contain this info, are here:
conflict detection and sync
https://docs.aws.amazon.com/appsync/latest/devguide/conflict-detection-and-sync.html
transactions
https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-dynamodb-transact.html
batch writes
https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-dynamodb-batch.html

Describe the solution you'd like

Two conclusions

• I spent a whole day on this and didn't find the information till the implementation ended up with the not supported. So even if I did miss the information somewhere, it should be much more prominent.
• Google did not return any helpful results when searching for the keywords for this issue. By posting here, I can at least make this issue more visible. I have included the exact errors, and key terms, so hopefully this tickets existence will return results to the next dev who tries this.

Why post here:

There doesn't seem to be a great community for AppSync. I've found a repo here, but it seems fairly inactive. AppSync its self isn't open source, so I understand. Also, most people (like myself) seem to come to AppSync by way of Amplify. Writing resolvers for Amplify requires reading the AppSync documentation anyway, so this seems the most appropriate place for the issue.

Bonus Points!!!

Why are TransactWriteItems and BatchGetItem unsupported with Conflict Resolution? My experience implementing many databases has been - that for real world, commercial apps, concurrency requires both:

• Database Versioning
• Transaction Isolation

I really don't know any other way to get a highly concurrent app. Transactions unfortunately slow down the app, but there are inevitable use cases, (usually for internal users), that always require a consistent multi item write. Since TransactWriteItems exists clearly locks can be set on a DynamoDB resource.

Describe alternatives you've considered

Only two solutions I can see:

1. Abandon AppSync conflict resolution and implement my own system.
2. Implement a lambda function that goes behind AppSync's back and works directly on the underlying DynamoDB.

My go to solution when a multi-item write is required is:

1. lock the resource (start a transaction)
2. do a fully ACID write to the db.
3. roll back if error
4. unlock the db
5. process conflict resolution across all clients
   a. re-fetch any stale data when ttl expires
   b. throw out any writes with old row versions and notify client of error so they can re-fetch and try again.

I'm going to make the bold claim that this is the only way to get air tight concurrency. There are lots of ways to implement, but this strategy is sort of a must, because otherwise you can be trying to deconflict a data set where several partial writes by several clients have happened, resulting in you data being in a "broken state". Good luck deconflicting that to everyone's satisfaction!!

To implement a conflict resolution feature all you need is a table you can write to.
It's all done by adding metadata fields to data and processing them client side.

To implement a transaction isolation feature, you need control of locks.
AppSync only gives control of locks as transactions. Turned off by Conflict Resolution.

AppSync's pre-existing conflict resolution is a really, really good implementation. A shame that we are just forbidden access to resource locks.

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

[chrisbonifacio]

Hi @jmarshall9120 👋 thank you for raising this issue. I'm bringing it to the AppSync service team as feedback to get the documentation updated with a callout and will try to get some feedback for the alternative solutions you're considering as well.

Just out of curiosity and not seeing it mentioned in the description, but how did you eventually realize the cause of the issue was that Conflict detection was enabled?