feat: Custom type and ref arg handling in SchemaProcessor with tests

[vaisshnavi7]

Problem:
-Custom type and ref arguments in custom queries and mutations were not properly handled in the SchemaProcessor, leading to incorrect GraphQL schema generation.
-Several integration tests in custom-operations.ts were previously skipped due to schema validation issues related to custom type argument features.

Related PR
-This PR addresses the skipped tests and completes the implementation started in PR #402.

Changes:

• Updated SchemaProcessor.ts to generate GraphQL input types for custom types and ref arguments.
• Modified the processing of custom operations to use these generated input types.
• Implemented generateInputTypes function to create GraphQL input types for custom structures.
• Expanded and fixed integration tests in custom-operations.ts:
  • Re-enabled previously skipped tests
  • Added new test for schema.transform() to ensure correct schema generation
  • Added new tests for mocked runtime behavior of client operations with custom type and ref arguments
• Updated test snapshots to reflect new schema generation behavior
• Adjusted test cases in CustomOperations.test.ts, client-schema.ts, and ssr-req-client.ts

Validation:

• Expanded existing integration tests in custom-operations.ts to cover new functionality, including:
  • A new test for schema.transform() to verify correct schema generation
  • New tests for mocked client operations with custom type and ref arguments
• Re-enabled and fixed previously skipped tests in custom-operations.ts
• Verified that all tests now pass, including those for custom types and ref arguments
• Deployed the schema using a sample application to verify:
  • Schema generation matches expectations.
  • Deployment succeeds without errors.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[changeset-bot]

⚠️ No Changeset found

Latest commit: e7493a3

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[iartemiev]

I'm seeing some unexpected changes in the code and tests/snapshots, as called out in the comments.

Let's baseline on the requirements. When custom query/mutation arguments contain non-scalar values (e.g., custom types or a refs to custom types), we should:

1. Define a GraphQL Input type from the arguments in the SDL output from schema.transform()
2. Reference this input type in the query/mutation field argument
3. The GraphQL Type definition for the custom type should remain in the SDL output

For example, given:

Location: a.customType({
  lat: a.float(),
  long: a.float(),
}),

addLocationToPost: a
  .mutation()
  .arguments({ postId: a.string(), location: a.ref('Location') })
  .handler(a.handler.custom({ entry: './source.js' }))
  .returns(a.boolean())

The GraphQL output should be:

type Location 
{
  lat: Float
  long: Float
}

input AddLocationToPostLocationInput 
{
  lat: Float
  long: Float
}

type Mutation {
  addLocationToPost(postId: string, location: AddLocationToPostLocationInput): Boolean
}

However, when I pull down the PR and run schema.transform() on the same schema , I get the following output:

type Location 
{
  lat: Float
  long: Float
}

type Mutation {
  addLocationToPost(postId: String, location: ID): Boolean
}

• Input type is not getting generated
• addLocationToPost field arg location is referencing type ID instead of the Input type

After making the requested changes, I recommend linking @aws-amplify/data-schema into a sample app and actually attempting to deploy some schemas with custom operations containing non-scalar arguments to make sure everything works as expected.

[stocaaro]

How is the unit test branch coverage of the code we're introducing in this change?

[iartemiev]

Here and below, I'm seeing that the auth graphql directives (@aws_api_key, @aws_cognito_user_pools, etc.) are now getting dropped from the generated types.

Does this PR actually need to change anything about how return types are handled relative to main? I could be wrong, but AFAIK, we already support custom types and refs to custom types as the return types for custom queries and mutations.

[iartemiev]

Thanks for making the requested changes.

Approving merge to the feat branch.

There are a few changes in SchemaProcessor.ts that I'd like to review more closely, but I will defer that until the feat -> main PR is ready.