Query on secondary index throws without error

[kekami]

Environment information

System:
  OS: macOS 14.4.1
  CPU: (10) arm64 Apple M1 Max
  Memory: 184.45 MB / 32.00 GB
  Shell: /bin/zsh
Binaries:
  Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
  Yarn: 1.22.22 - ~/.nvm/versions/node/v18.20.0/bin/yarn
  npm: 10.5.0 - ~/.nvm/versions/node/v20.12.2/bin/npm
  pnpm: 8.15.6 - /opt/homebrew/bin/pnpm
NPM Packages:
  @aws-amplify/backend: 1.0.0
  @aws-amplify/backend-cli: 1.0.1
  aws-amplify: 6.2.0
  aws-cdk: 2.137.0
  aws-cdk-lib: 2.137.0
  typescript: 5.4.5
AWS environment variables:
  AWS_SDK_LOAD_CONFIG = 1
  AWS_STS_REGIONAL_ENDPOINTS = regional
  AWS_NODEJS_CONNECTION_REUSE_ENABLED = 1
No CDK environment variables

Description

Created a simple reproducable schema:

const schema = a.schema({
  Project: a
    .model({
      userId: a.string().required(),
      publishedAt: a.datetime().required(),
    })
    .authorization((allow) => [allow.authenticated()])
    .secondaryIndexes((index) => [index("userId").sortKeys(["publishedAt"])]),
});

When trying to query using the generated .listProjectByUserIdAndPublishedAt function, it throws without an error message.

Example App.tsx

import { useEffect } from "react";

import "./App.css";
import { generateClient } from "aws-amplify/api";
import { Schema } from "../amplify/data/resource";
import { Amplify } from "aws-amplify";
import outputs from "../amplify_outputs.json";

Amplify.configure(outputs);

const client = generateClient<Schema>();

function App() {
  useEffect(() => {
    (async () => {
      try {
        const { data, errors } =
          await client.models.Project.listProjectByUserIdAndPublishedAt({
            userId: "l32khj32",
            publishedAt: { gt: new Date().toISOString() },
          });

        // Never reaches here
        console.warn({ data, errors });
      } catch (e) {
        // Logs {}
        console.warn(JSON.stringify(e));
      }
    })();
  }, []);

  return (
    <>
      <div />
    </>
  );
}

export default App;

[kekami]

Debugging Appsync I uncovered the underlying error message:

{
    "logType": "GraphQLFieldValidationError",
    "fieldInError": true,
    "path": [
        "null"
    ],
    "errors": [
        "Validation error of type UnknownType: Unknown type ModelAWSDateTimeKeyConditionInput"
    ],
    "requestId": "fe2df959-8e31-41ec-beb3-89cdd129d033",
    "graphQLAPIId": "eqbbb3ucprczjnretbat3g7zli"
}

[ykethan]

hey👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂

[renebrandel]

@kekami - we're actively working on it. We've almost gotten the fix wrapped up.

[ChristopherGabba]

+1 on this error, except all of my secondary index queries are throwing: [TypeError: Cannot convert null value to object].

// model
Friendship: a
    .model({
      id: a.id().required(),
      receiverId: a.id().required(),
      receiver: a.belongsTo("User", "receiverId"),
      senderId: a.id().required(),
      sender: a.belongsTo("User", "senderId"),
      status: a.ref("FriendStatus").required(),
    })
    .authorization((allow) => [allow.publicApiKey()])
    .secondaryIndexes((index) => [
      index("senderId")
        .name("bySender")
        .sortKeys(["receiverId"])
        .queryField("listFriendshipsBySenderId"),
      index("receiverId")
        .name("byReceiver")
        .sortKeys(["senderId"])
        .queryField("listFriendshipsByReceiverId"),
    ])

    // code
    const currentUser = await getCurrentUser()

     const client = generateClient<Schema>()
    
     const response = await client.models.Friendship.listFriendshipsByReceiverId({ <--- throwing error every time
          receiverId: currentUser.userId,
     })

I have checked if the getCurrentUser is

[iartemiev]

We've patched this bug in the latest release of @aws-amplify/data-schema. Please run npm update @aws-amplify/data-schema to consume the patch.

[github-actions[bot]]

This issue is now closed. Comments on closed issues are hard for our team to see. If you need more assistance, please open a new issue that references this one.