Type instantiation infinite depth error when using args in authScopes on a .authField method

[TremainEnergyFlex]

Hi,
when using the .authField method, using the args variable in the function passed to authScopes causes type instantiation to go infinite. The docs seem to suggest such a thing should be possible, but the only example is on the t.exposeInt method, which results in the args being untyped. I am currently working around it by using the .withAuth method and manually casting the args to the desired type.

In most cases I would put the authScope requirement on the actual Type itself. However when it comes to mutations, I need to know ahead of time because the mutation will do many different things, and may not even return an object until after it has been modified.

Is there any way to automatically get the typing from the args of the field so that I can cast to it safely? If not, is it possible to use a shared type for both the args on the field and the args on authScopes/.withAuth? Could this be done by building the args separately to the authScopes? (if that is possible)

I have some example code showing the situation:

Builder:

// authScopes on my builder
export const builder = new SchemaBuilder<{
    ...
    PrismaTypes: PrismaTypes;
    AuthScopes: {
      "organisation:staff": string
    },
    ...
}>({
  ...
  plugins: [ScopeAuthPlugin, PrismaPlugin],
  prisma: {
    client: prisma,
  },
  scopeAuth: {
    authScopes: async (context) => ({
      "organisation:staff": (organisationId) => context.permissionService.isOrganisationStaff({ userId: context.user.id, organisationId }),
    })
  },
  ...
});
builder.mutationType({});
builder.queryType({});

Errors with 'Type instantiation is excessively deep and possibly infinite.':

// Errors with 'Type instantiation is excessively deep and possibly infinite.'
builder.mutationField("updateOrganisationDescription", (t) =>
  t.authField({
    type: "Organisation",
    args: {
      organisationId: t.input.string({ required: true }),
      description: t.input.string({ required: true }),
    },
    authScopes: (parent, args) => ({
      "organisation:staff": args.organisationId,
    }),
    resolve: async (_root, _args, _ctx, _info) => {
      return prisma.organisation.update({
        where: { id: _args.organisationId },
        data: { description: _args.description },
      });
    },
  })
);

Examples using the .withAuth method instead:

    //Examples using the `.withAuth` method instead:
    t.withAuth((parent, args) => ({ //args: Record<string, unknown>
      "organisation:staff": args.organisationId, // Error: Type 'unknown' is not assignable to type 'string | undefined'
    }))

    t.withAuth((parent, args: Record<string, string>) => ({ // Error: Type 'unknown' is not assignable to type 'string'
      "organisation:staff": args.organisationId,
    }))

    t.withAuth((parent, args: { organisationId: string; description: string }) => ({ // Error: Types of parameters 'args' and 'args' are incompatible.
      "organisation:staff": args.organisationId,
    }))

Current workaround is using .withAuth and then manually casting the args to go into the scopeloader:

builder.mutationField("updateOrganisationDescription", (t) =>
  t.withAuth((parent, args) => ({ //args: Record<string, unknown>
      "organisation:staff": args.organisationId as string, // Current workaround, have to manually cast to string to use this authScope.
    }))
    .prismaField({
      type: "Organisation",
      args: {
        organisationId: t.input.string({ required: true }),
        description: t.input.string({ required: true }),
      },
      resolve: async (_query, _root, _args, _ctx, _info) => {
        return prisma.organisation.update({
          ..._query,
          where: { id: _args.organisationId },
          data: { description: _args.description },
        });
      },
    })
);

[hayes]

withAuth and authField are both meant to be used with AuthContexts.

If you don't need AuthContexts for this field, just using t.field should work fine here (based on the example it doesn't look like you would need this)

Here's 2 versions that do work:

builder.mutationField('updateOrganisationDescription', (t) =>
  t.field({
    type: 'Organisation',
    args: {
      organisationId: t.arg.string({ required: true }),
      description: t.arg.string({ required: true }),
    },
    authScopes: (parent, args) => ({
      'organisation:staff': args.organisationId,
    }),
    resolve: async (_root, args, _ctx, _info) => {
      return { id: args.organisationId };
    },
  })
);

builder.mutationField('updateOrganisationDescription', (t) =>
  t.authField({
    type: 'Organisation',
    args: {
      organisationId: t.arg.string({ required: true }),
      description: t.arg.string({ required: true }),
    },
    authScopes: (parent: unknown, args: Record<string, string>) => ({
      'organisation:staff': args.organisationId,
    }),
    resolve: async (_root, args, _ctx, _info) => {
      return { id: args.organisationId };
    },
  })
);

There is definitely something going wrong here though, but hopefully one of the options above will be a sufficient workaround until I can fix the underlying issue

[TremainEnergyFlex]

Whoops, I forgot the AuthContexts from the builder.

We copied the auth plugin docs directly for this one so we have the Context & {user: user} context defined for this authScope. You are correct though, since this mutation doesn't require the context we should just user .field

However in some other mutations we use both .prismaField (or other plugin fields) and rely on the AuthContexts typing, so we do end up using .withAuth. One of my team members actually prefers to use .withAuth because it reminds him of Rust lol.

Your second workaround works great though. For now we will continue to use field/prismaField when no context typing is required, and use your workaround with authField when the AuthContexts is needed. We only have a few cases where we need to use .withAuth so in those cases we can just explicitly cast as before.

Thanks!

[hayes]

I dug into this a bit, and unfortunately there isn't a way to fix this.

There is a limitation in typescript that prevents inferring both the arguments and return type of a function (with some specific exceptions).

Basically if we change things so the args for authScopes are inferred correctly, the return type can't be inferred to be used to define the context type.

Typing the args (as shown in my workaround above) is probably your best bet.

I'll probably update the docs to suggest that when using authField with a function.

We can probably fix the type error so it's not an infinite depth error, but I don't think this can actually work without explicit types somewhere

[TremainEnergyFlex]

No worries, thanks for looking into it.

I've been working on it a bit more and hacked together a way to move the type declaration to a single place least. If I build an inputType I can use $inferInput to infer the type, and then use it as the explicit type for the args:

const UpdateOrganisationDescriptionInput = builder.inputType("UpdateOrganisationDescription", {
  fields: (t) => ({
    organisationId: t.string({ required: true }),
    description: t.string({ required: true }),
  }),
});

builder.mutationField("updateOrganisationDescription", (t) =>
  t.withAuth((_root, { input }) => ({
    "organisation:staff": (input as typeof UpdateOrganisationDescriptionInput.$inferInput).organisationId,
  }))
  .prismaField({
    type: "Organisation",
    args: {
      input: t.arg({ type: UpdateOrganisationDescriptionInput, required: true }),
    },
    resolve: async (query, _root, { input }, ctx, _info) => {
      // ctx is typed according to the AuthContexts
      if (ctx.user.lastName !== "some random check") {
        // Do something
      }
      return prisma.organisation.update({
        ...query,
        where: { id: input.organisationId },
        data: {
          description: truncate(input.description, { length: 500 }),
        },
      });
    },
  })
);

This way, if someone updates the input for the mutation, the withAuth will cause a type error if it tries to use a field that doesn't exist