aws-amplify / aws-amplify/amplify-data
indexQuery does not return `errors` from GraphQL response (unlike `list`)
- Dominant language
- TypeScript
- Stars
- 18
- Forks
- 23
- Avg merge
- 26m
- Merged PRs (30d)
- 1
Description
## Describe the bug
The `indexQuery` implementation in [`packages/data-schema/src/runtime/internals/operations/indexQuery.ts`](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/indexQuery.ts) does not include the `errors` field in its return value, while the equivalent [`list.ts`](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/list.ts) implementation does.
When a GraphQL response contains both `data` and `errors` (e.g., partial errors from AppSync pipeline resolvers using `util.appendError()`), the `list` operation correctly returns `{ data, nextToken, errors }`, but `indexQuery` only returns `{ data, nextToken }` — silently dropping the errors.
We would like to understand whether this is an intentional design decision or an unintended omission. If intentional, could you explain the reasoning behind the difference in behavior between `list` and `indexQuery`?
**Affected code ([`indexQuery.ts` L200-224](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/indexQuery.ts#L200-L224)):**
```typescript
// errors is destructured but never included in the return value
const { data, errors } = error;
if (data[key]?.items) {
const flattenedResult = ...;
if (flattenedResult) {
return {
data: args?.selectionSet ? flattenedResult : modelInitializer(flattenedResult),
nextToken: data[key]?.nextToken,
// ❌ missing: errors
};
}
}
return {
data: data[key],
nextToken: data[key]?.nextToken,
// ❌ missing: errors
};
```
**Corresponding code ([`list.ts` L195-227](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/list.ts#L195-L227)):**
```typescript
const { data, errors } = error;
if (data[key]?.items) {
const flattenedResult = ...;
if (flattenedResult) {
return {
data: flattenedResult,
nextToken: data[key]?.nextToken,
errors, // ✅ included
};
}
}
```
The same inconsistency also exists in [`processGraphQlResponse()`](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/indexQuery.ts#L78-L107) (the happy path) — it returns `{ data, nextToken, extensions }` but does not return `errors`.
## To Reproduce
1. Define a model with a secondary index:
```typescript
Todo: a
.model({ title: a.string(), ownerId: a.id().required(), status: a.string() })
.secondaryIndexes((index) => [index("ownerId").sortKeys(["status"])])
```
2. Set up an AppSync pipeline resolver that calls `util.appendError()` (e.g., a custom authorization resolver that appends errors for denied items)
3. Call the index query from the frontend:
```typescript
const { data, errors } = await client.models.Todo.listTodoByOwnerIdAndStatus({
ownerId: "user-123",
status: { eq: "active" },
});
```
4. `errors` is always `undefined`, even when the GraphQL response contains errors
## Expected behavior
`errors` should be returned from index query operations, consistent with the `list` operation behavior. The return value should be `{ data, nextToken, errors }`.
## Desktop (please complete the following information)
- OS: macOS
- `@aws-amplify/data-schema`: 1.21.0
- `aws-amplify`: ^6.15.3
## Additional context
This affects any use case where AppSync resolvers use `util.appendError()` with secondary index queries. In our case, custom authorization pipeline resolvers use `util.appendError()` to notify the frontend about access control errors, but these errors are silently dropped when the query goes through `indexQuery`.
Would it be reasonable to add `errors` to the return statements in [`indexQuery.ts`](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/indexQuery.ts) to match the behavior of [`list.ts`](https://github.com/aws-amplify/amplify-data/blob/main/packages/data-schema/src/runtime/internals/operations/list.ts)? If there is a specific reason for the current behavior, we would appreciate guidance on the recommended way to handle errors from index queries on the client side.
Contributor guide
Research direction
Read packages/data-schema/src/runtime/internals/operations/indexQuery.ts, especially processGraphQlResponse() and the return paths around lines 200-224, then compare them with list.ts. Use the AppSync util.appendError() reproduction to verify behavior; done means index queries preserve GraphQL errors alongside data and nextToken in both partial-error and happy-path responses.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- graphql, typescript
- Domain
- api
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100