Amplify GraphQL AppSync数据返回逻辑异常问题：创建Order后可通过ID查询但列表查询无法获取该数据

Hey there! Let's figure out why your newly created Order isn't showing up in the listOrders query, even though you can fetch it just fine with getOrder. This is a common gotcha with Amplify, AppSync, and DynamoDB, so let's break down the most likely causes and fixes:

1. Default User Filtering from the @belongsTo Association #

When you add the @belongsTo directive to the user field in your Order type, Amplify automatically sets up authorization rules that filter list queries to only return records linked to the currently authenticated user. Here's what's probably happening:

• When you created the Order, you didn't include the required userId foreign key (Amplify generates this field behind the scenes for @belongsTo relationships).
• The getOrder query skips this filter because it's fetching directly by the primary key id, but listOrders applies the default filter to only show orders tied to your current user's ID.

How to Fix This: #

• First, check your DynamoDB table for the Order item—does it have a userId value? You can verify this straight from the AWS Console.
• When creating an Order, make sure to include the userId field (or properly associate it with a User item using your client code). For example, your mutation should look something like this:

  mutation CreateOrder {
    createOrder(input: {ref: "ORD-456", userId: "user-789"}) {
      id
      ref
      userId
    }
  }
  

• If you need to disable this default filtering (only do this if it aligns with your security requirements), add an @auth directive to your Order type to allow unfiltered read access:

  type Order @model @searchable @auth(rules: [{allow: public, operations: [read]}]) {
    id: ID! @primaryKey
    ref: String!
    user: User @belongsTo
  }
  

2. Synchronization Delay from @searchable #

The @searchable directive syncs your DynamoDB data to an OpenSearch domain using DynamoDB Streams. If your listOrders query is using the search-backed resolver (Amplify often generates both search and direct DynamoDB resolvers when @searchable is added), there might be a delay between when the Order is created in DynamoDB and when it's indexed in OpenSearch.

How to Check & Fix: #

• Confirm which resolver listOrders is using: Head to the AppSync Console, go to your API's Queries tab, and look at the resolver details for the listOrders query.
• If it's using the search resolver, wait 1-2 minutes and try again—indexing usually takes a few seconds, but can lag if there's a backlog.
• If you don't need full-text search for Orders, you can remove the @searchable directive entirely. This will make listOrders directly query DynamoDB without any indexing delays.

3. DynamoDB Read Consistency Settings #

By default, Amplify's list queries use eventual consistency for DynamoDB reads. In rare cases, if you run listOrders immediately after creating the Order, the data might not have propagated to all DynamoDB replicas yet.

How to Fix: #

• Modify the listOrders resolver to use strong consistency:
  1. Open the AppSync Console and navigate to your API > Resolvers.
  2. Find the listOrders resolver linked to the Query type.
  3. Edit the resolver template and set consistentRead to true in the DynamoDB scan/query operation. Here's an example snippet:

     {
       "version": "2017-02-28",
       "operation": "Scan",
       "consistentRead": true,
       "limit": $util.defaultIfNull($context.args.limit, 20),
       "nextToken": $util.toJson($context.args.nextToken)
     }
     

Start with checking the userId field first—it's the most common culprit here. Let me know if any of these fixes work for you!

内容的提问来源于stack exchange，提问作者amineRd