Hotfix for typescript react query infinite query breaking change #8567

EandrewJones · 2022-11-02T17:27:35Z

Description

As per @marcmll's comment #8497 (comment), the change introduced in PR #8497 breaks infinite query calls for some users if pageParam is undefined which happen on the first call.

Related #8566

The code now safeguards against this via a ternary operator that check whether pageParam is defined and only overwrites variable value when it's defined.

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Updated the typescript-react-query plugin test suite (packages/plugins/typescript/react-query/tests/react-query.spec.ts) to match the new outputs

Test Environment:

OS: Ubuntu 18.04
NodeJS: v14.20.1

Checklist:

I have followed the CONTRIBUTING doc and the style guidelines of this project
I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

…Param to pageParamKey only when it is defined

changeset-bot · 2022-11-02T17:27:38Z

🦋 Changeset detected

Latest commit: cc7f529

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@graphql-codegen/typescript-react-query	Patch

Not sure what this means? Click here to learn what changesets are.

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

marcmll

Thank you so much for your quick response and for opening a hotfix so quickly!

EandrewJones · 2022-11-03T00:35:54Z

My apologies for breaking your code. There's nothing worse than updating a package and everything stops working. Best Evan Jones Website: www.ea-jones.com

…

On Wed, Nov 2, 2022 at 6:16 PM Marc Müller ***@***.***> wrote: ***@***.**** approved this pull request. Thank you so much for your quick response and for opening a hotfix so quickly! — Reply to this email directly, view it on GitHub <#8567 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2T6AOJ4776QXFHTRPPLDLWGLR3TANCNFSM6AAAAAARVKNY4E> . You are receiving this because you authored the thread.Message ID: ***@***.***>

wileymc · 2022-11-03T21:01:11Z

this is great work! lets get this merged :)

saihaj · 2022-11-04T16:22:17Z

https://github.com/dotansimha/graphql-code-generator/releases/tag/release-1667578711788

wileymc · 2022-11-05T00:37:09Z

Interesting, after updating I'm still getting tsc complaining about:

Argument of type '{ [x: string]: any; }' is not assignable to parameter of type 'Exact<{ [key: string]: never; }>'.
  'string' index signatures are incompatible.
    Type 'any' is not assignable to type 'never'.

for infinite queries. any ideas?

EandrewJones · 2022-11-05T02:02:52Z

Hmm. I'll try to take a look at this tomorrow. Could you provide an example of the query call you're making and the fetcher you're using? Best Evan Jones Website: www.ea-jones.com

…

On Fri, Nov 4, 2022 at 8:37 PM Wiley McKay Conte ***@***.***> wrote: Interesting, after updating I'm still getting tsc complaining about: Argument of type '{ [x: string]: any; }' is not assignable to parameter of type 'Exact<{ [key: string]: never; }>'. 'string' index signatures are incompatible. Type 'any' is not assignable to type 'never'. for infinite queries. any ideas? — Reply to this email directly, view it on GitHub <#8567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2T6AKYCVEX3H4YMYCEZS3WGWT4BANCNFSM6AAAAAARVKNY4E> . You are receiving this because you authored the thread.Message ID: ***@***.***>

wileymc · 2022-11-05T23:44:35Z

Hi @EandrewJones. Here is one example of this in a generated query: https://github.com/populist-vote/web/blob/w/upgrade-rq/generated.ts#L3676-L3679

Our codegen.yml: https://github.com/populist-vote/web/blob/w/upgrade-rq/codegen.yml

And the associated .gql: https://github.com/populist-vote/web/blob/w/upgrade-rq/graphql/mutations/auth.graphql#L13-L33

Note, the offending generated hooks are for queries that we'll never need an infinite query for so perhaps there is a way to simply ignore these?

I can get to get a minimal reproducible example if you need! Thanks for your attention on this

EandrewJones · 2022-11-05T23:59:57Z

Thanks for sharing. Update: I probably won't be able to look deeply into this until Monday. Is it breaking your type checks on commit/deploy? Best Evan Jones Website: www.ea-jones.com

…

On Sat, Nov 5, 2022 at 7:44 PM Wiley McKay Conte ***@***.***> wrote: Hi @EandrewJones <https://github.com/EandrewJones>. Here is one example of this in a generated query: https://github.com/populist-vote/web/blob/w/upgrade-rq/generated.ts#L3676-L3679 Our codegen.yml: https://github.com/populist-vote/web/blob/w/upgrade-rq/codegen.yml And the associated .gql: https://github.com/populist-vote/web/blob/w/upgrade-rq/graphql/mutations/auth.graphql#L13-L33 Note, the offending generated hooks are for queries that we'll never need an infinite query for so perhaps there is a way to simply ignore these? I can get to get a minimal reproducible example if you need! Thanks for your attention on this — Reply to this email directly, view it on GitHub <#8567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2T6AKPHD3FCLV5B7OY7HTWG3WO3ANCNFSM6AAAAAARVKNY4E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

wileymc · 2022-11-06T00:44:56Z

No worries, its breaking type checks on build but its not blocking or pressing at all. Thanks for investigating!

…

On Nov 5, 2022, at 18:00, Evan Jones ***@***.***> wrote: Thanks for sharing. Update: I probably won't be able to look deeply into this until Monday. Is it breaking your type checks on commit/deploy? Best Evan Jones Website: www.ea-jones.com On Sat, Nov 5, 2022 at 7:44 PM Wiley McKay Conte ***@***.***> wrote: > Hi @EandrewJones <https://github.com/EandrewJones>. Here is one example > of this in a generated query: > https://github.com/populist-vote/web/blob/w/upgrade-rq/generated.ts#L3676-L3679 > > Our codegen.yml: > https://github.com/populist-vote/web/blob/w/upgrade-rq/codegen.yml > > And the associated .gql: > https://github.com/populist-vote/web/blob/w/upgrade-rq/graphql/mutations/auth.graphql#L13-L33 > > Note, the offending generated hooks are for queries that we'll never need > an infinite query for so perhaps there is a way to simply ignore these? > > I can get to get a minimal reproducible example if you need! Thanks for > your attention on this > > — > Reply to this email directly, view it on GitHub > <#8567 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AJ2T6AKPHD3FCLV5B7OY7HTWG3WO3ANCNFSM6AAAAAARVKNY4E> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub <#8567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHLDEUPZDZF2L74G5YCPQOTWG3YIRANCNFSM6AAAAAARVKNY4E>. You are receiving this because you commented.

EandrewJones · 2022-11-08T02:18:36Z

@wileymc

Are the type warnings appearing in https://github.com/populist-vote/web/blob/w/upgrade-rq/generated.ts itself or in front-end front-end query calls itself?

I'm a bit confused on where you're seeing the issue since you said the offending hooks are for queries that you'll never need an infinite query for, which suggests to me that the warnings must be in the generated.ts file itself.

Is the entire query underlined by your linter or just a specific part? I'm trying to replicate this but I can't.

wileymc · 2022-11-08T03:17:13Z

@wileymc

Are the type warnings appearing in https://github.com/populist-vote/web/blob/w/upgrade-rq/generated.ts itself or in front-end front-end query calls itself?

I'm a bit confused on where you're seeing the issue since you said the offending hooks are for queries that you'll never need an infinite query for, which suggests to me that the warnings must be in the generated.ts file itself.

Is the entire query underlined by your linter or just a specific part? I'm trying to replicate this but I can't.

I'm not consuming any of the offending generated hooks. The warnings are indeed in the generated file:

Argument of type '{ [x: string]: any; }' is not assignable to parameter of type 'Exact<{ [key: string]: never; }>'.
  'string' index signatures are incompatible.
    Type 'any' is not assignable to type 'never'.ts(2345)

However, I am noticing that one of the infinite query hooks that I am consuming is now failing at runtime when making a call for the next page.

Error: Invalid value for argument "after", expected type "String"`

The hooks usage looks like this:

  const {
    data,
    isLoading,
    error,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
  } = useInfinitePoliticianIndexQuery(
    "cursor",
    {
      pageSize: PAGE_SIZE,
      filter: {
        query: debouncedSearchQuery || null,
        homeState: state as State,
        politicalScope: scope as PoliticalScope,
        chambers: chamber as Chambers,
      },
    },
    {
      queryKey: [
        "politicianIndex",
        debouncedSearchQuery,
        scope,
        chamber,
        state,
      ],
      getNextPageParam: (lastPage) => {
        if (!lastPage.politicians.pageInfo.hasNextPage) return {};
        return {
          cursor: lastPage.politicians.pageInfo.endCursor,
        };
      },
    }
  );

In debugging, i've logged out lastPage.politicians.pageInfo.endCursor and it is defined and indeed a string. May be something to do with react-query v4

Let me know if you need any other information, thank you

EandrewJones · 2022-11-08T17:06:19Z

@wileymc

Type Mismatch

The issue with the type checking is that CurrentUserQuery doesn't accept any variables. So there's a type mismatch between the type definition for CurrentUserQueryVariables:
https://github.com/populist-vote/web/blob/37fb984b378497cfc7de572301287bd92ec98df4/generated.ts#L1754

and the unpacking that's happening during pagination:

        {
          ...variables,
          ...(metaData.pageParam ? { [pageParamKey]: metaData.pageParam } : {}),
        }

What confuses me here is how you're storing currentUser (client-side state) in a database and looking it up without passing any variables such as a userId to the query??

For example, I see similar logic in DeleteAccount: https://github.com/populist-vote/web/blob/37fb984b378497cfc7de572301287bd92ec98df4/generated.ts#L1947

How does the back end know which account to delete if you're not passing a key of some sort?

I'm definitely missing something important here.

Fix for the broken calls

However, I am noticing that one of the infinite query hooks that I am consuming is now failing at runtime when making a call for the next page.
Error: Invalid value for argument "after", expected type "String"`
The hooks usage looks like this:
  const {
    data,
    isLoading,
    error,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
  } = useInfinitePoliticianIndexQuery(
    "cursor",
    {
      pageSize: PAGE_SIZE,
      filter: {
        query: debouncedSearchQuery || null,
        homeState: state as State,
        politicalScope: scope as PoliticalScope,
        chambers: chamber as Chambers,
      },
    },
    {
      queryKey: [
        "politicianIndex",
        debouncedSearchQuery,
        scope,
        chamber,
        state,
      ],
      getNextPageParam: (lastPage) => {
        if (!lastPage.politicians.pageInfo.hasNextPage) return {};
        return {
          cursor: lastPage.politicians.pageInfo.endCursor,
        };
      },
    }
  );
In debugging, i've logged out lastPage.politicians.pageInfo.endCursor and it is defined and indeed a string. May be something to do with react-query v4

Let me know if you need any other information, thank you

Well this one is more apparent: your getNextPageParam function isn't just returning lastPage.poiticians.pageInfo.endCursor, it's returning an object with a cursor field. You only need to return lastPage.poiticians.pageInfo.endCursor and the hook should work.

      getNextPageParam: (lastPage) => {
        if (!lastPage.politicians.pageInfo.hasNextPage) return ''; // Might need to change this to undefined or change the logic so this callback isn't even triggered unless hasNextPage is true
        return lastPage.politicians.pageInfo.endCursor;
      },

The way the code was changed, the infiniteQuery no longer unpacks the pageParam object ...(metaData.pageParam ?? {}) instead it simply expects the value for the pageParamKey.

Originally, I thought this was the issue, but now I believe all I needed to fix was the missing pageParamKey argument in the custom-fetcher generation files...

blaenk · 2022-11-10T05:07:44Z

Also experiencing this issue. Is there already an issue to track it? Not sure if it's dotansimha/graphql-code-generator-community#227

EandrewJones · 2022-11-10T17:32:08Z

@blaenk Yes this is tracking the issue.

This is on my radar and I'll try to figure out the appropriate solution in a new PR soon.

wileymc · 2022-11-10T17:35:26Z

@wileymc

Type Mismatch

The issue with the type checking is that CurrentUserQuery doesn't accept any variables. So there's a type mismatch between the type definition for CurrentUserQueryVariables: https://github.com/populist-vote/web/blob/37fb984b378497cfc7de572301287bd92ec98df4/generated.ts#L1754

and the unpacking that's happening during pagination:
        {
          ...variables,
          ...(metaData.pageParam ? { [pageParamKey]: metaData.pageParam } : {}),
        }
What confuses me here is how you're storing currentUser (client-side state) in a database and looking it up without passing any variables such as a userId to the query??

For example, I see similar logic in DeleteAccount: https://github.com/populist-vote/web/blob/37fb984b378497cfc7de572301287bd92ec98df4/generated.ts#L1947

How does the back end know which account to delete if you're not passing a key of some sort?

I'm definitely missing something important here.

Fix for the broken calls
However, I am noticing that one of the infinite query hooks that I am consuming is now failing at runtime when making a call for the next page.
Error: Invalid value for argument "after", expected type "String"`
The hooks usage looks like this:
  const {
    data,
    isLoading,
    error,
    fetchNextPage,
    hasNextPage,
    isFetchingNextPage,
  } = useInfinitePoliticianIndexQuery(
    "cursor",
    {
      pageSize: PAGE_SIZE,
      filter: {
        query: debouncedSearchQuery || null,
        homeState: state as State,
        politicalScope: scope as PoliticalScope,
        chambers: chamber as Chambers,
      },
    },
    {
      queryKey: [
        "politicianIndex",
        debouncedSearchQuery,
        scope,
        chamber,
        state,
      ],
      getNextPageParam: (lastPage) => {
        if (!lastPage.politicians.pageInfo.hasNextPage) return {};
        return {
          cursor: lastPage.politicians.pageInfo.endCursor,
        };
      },
    }
  );
In debugging, i've logged out lastPage.politicians.pageInfo.endCursor and it is defined and indeed a string. May be something to do with react-query v4
Let me know if you need any other information, thank you
Well this one is more apparent: your getNextPageParam function isn't just returning lastPage.poiticians.pageInfo.endCursor, it's returning an object with a cursor field. You only need to return lastPage.poiticians.pageInfo.endCursor and the hook should work.
      getNextPageParam: (lastPage) => {
        if (!lastPage.politicians.pageInfo.hasNextPage) return ''; // Might need to change this to undefined or change the logic so this callback isn't even triggered unless hasNextPage is true
        return lastPage.politicians.pageInfo.endCursor;
      },
The way the code was changed, the infiniteQuery no longer unpacks the pageParam object ...(metaData.pageParam ?? {}) instead it simply expects the value for the pageParamKey.

Originally, I thought this was the issue, but now I believe all I needed to fix was the missing pageParamKey argument in the custom-fetcher generation files...

Thanks for the info on the infiniteQuery hook, I will give that a shot later today. Per my getCurrentUser and deleteAccount queries, they do not require any variables to be be passed because they rely on an http only cookie that is passed with the request which provides the server with all the context it needs to get/delete the user record

EandrewJones · 2022-11-10T17:42:11Z

@wileymc Cookie-based -- got it. Makes sense.

StampixSMO · 2022-11-21T15:08:50Z

Interesting, after updating I'm still getting tsc complaining about:
Argument of type '{ [x: string]: any; }' is not assignable to parameter of type 'Exact<{ [key: string]: never; }>'.
  'string' index signatures are incompatible.
    Type 'any' is not assignable to type 'never'.
for infinite queries. any ideas?

Also having this error for queries without any variables

EandrewJones · 2022-11-21T22:42:14Z

@wileymc @StampixSMO @marcmll

I spent some time looking into this. A conditional check against queryVariables that are of type Exact<{[key: string]: never}> is out of the question for various reasons.

I think a reversion to the original variable unpacking implementation is the only choice since I don't believe that was the original source of my issue and it also worked fine with your code. Original unpacking implementation:

{...variables, ...(metaData.pageParam ?? {})}

@wileymc This would mean that the fix for broken calls I gave you above would no longer work, but your prior implementation would.

If this sounds good by you, I'll go ahead and implement.

blaenk · 2022-11-21T22:46:16Z

This would mean that the fix for broken calls I gave you above would no longer work, but your prior implementation would.

Curious what that 'prior implementation' is? I'm interested as someone who didn't make any changes to my graphql-codegen config but can't currently generate code due to this issue. Do you mean that it will now work again without any changes, or is some change necessary and if so what is it? I personally don't mind if any changes are necessary, I'm just curious what it would entail.

Thank you so much for looking into this and working on it @EandrewJones!

wileymc · 2022-11-22T04:51:45Z

@wileymc @StampixSMO @marcmll

I spent some time looking into this. A conditional check against queryVariables that are of type Exact<{[key: string]: never}> is out of the question for various reasons.

I think a reversion to the original variable unpacking implementation is the only choice since I don't believe that was the original source of my issue and it also worked fine with your code. Original unpacking implementation:
{...variables, ...(metaData.pageParam ?? {})}
@wileymc This would mean that the fix for broken calls I gave you above would no longer work, but your prior implementation would.

If this sounds good by you, I'll go ahead and implement.

Thanks for taking a look! I decided to set addInfiniteQuery: false and simply wrap the generated .fetcher() for the query I need inifinite in a useInfiniteQuery

Because I don't have many queries that I need the infinite hook for, this is great for now and I don't have a preference for which implementation you go with.

EandrewJones · 2022-11-22T15:25:49Z

@blaenk Sorry for the vague language. By "prior implementation", I was referring to the getNextPageParam in @wileymc's code which broke when I made the original change.

If you haven't made any changes to your code to try to address the change introduced in this PR, then reverting should return your existing code to working state. The original way nextPageParam variables were unpacked and passed back into the query was:

{...variables, ...(metaData.pageParam ?? {})}

I thought this was a partial source of the issue I encountered because the pageParamKey wasn't being passed in during unpacking (unless you explicitly returned an object from the getNextPageParam function with the pageParamKey e.g. return {[pageParamKey]: pageParam}), but now I believe the problem was actually a missing line of code elsewhere. So, if I revert this line of code, I think everyone should be made whole again.

blaenk · 2022-11-22T21:48:56Z

If you haven't made any changes to your code to try to address the change introduced in this PR, then reverting should return your existing code to working state.

If by this you mean reverting the package version, yeah I pinned it to the previously working version, I didn't mean to convey I'm currently in a broken state, I only meant that it's broken with the current version 👍🏼

So if I understand you correctly, having not made any changes other than pinning to the previously working version, once the fix is out, the intention is that it'll work by simply upgrading to it.

Thanks again for your work on this!

EandrewJones · 2022-11-24T02:27:20Z

@blaenk That is the intention. Will update this thread when the PR is in. Might be a few days because of holidays.

hwennnn · 2023-01-16T10:01:49Z

any update on this?

EandrewJones · 2023-01-16T16:36:47Z

@hwennnn I've basically been stuck waiting on a reveiwer/admin to merge the dang PR.

The changes have been sitting and waiting. I pinged the reviewer on the PR to see if we can get this in.

blaenk · 2023-01-17T05:39:14Z

Looks like that other PR you mentioned is now merged. Nice work!

EandrewJones · 2023-01-17T16:21:29Z

Yes, thanks for all the nudges -- this slipped off my radar as it did the reviewer's. The codebase should now be almost completely reverted. Best Evan Jones Website: www.ea-jones.com

…

On Tue, Jan 17, 2023 at 12:39 AM Jorge Israel Peña ***@***.***> wrote: Looks like that other PR you mentioned is now merged. Nice work! — Reply to this email directly, view it on GitHub <#8567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2T6AP7MYQ6EKEWGTQRGU3WSYWAZANCNFSM6AAAAAARVKNY4E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

blaenk · 2023-01-17T18:50:27Z

It does appear to work for me, thanks again for your contribution on this!

EandrewJones · 2023-01-17T20:02:29Z

Thanks for the confirmation. Best Evan Jones Website: www.ea-jones.com

…

On Tue, Jan 17, 2023 at 1:50 PM Jorge Israel Peña ***@***.***> wrote: It does appear to work for me, thanks again for your contribution on this! — Reply to this email directly, view it on GitHub <#8567 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ2T6AKT74D7IK2D63W4QP3WS3SX5ANCNFSM6AAAAAARVKNY4E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

EandrewJones and others added 5 commits October 17, 2022 14:48

fixes issue #7549

757e2e3

update dev-test types #7549

07ff5a3

Create sweet-nails-tie.md

858902a

Merge branch 'master' of github.com:dotansimha/graphql-code-generator

17d2c70

fix breaking change in dotansimha#8566; optionally pass metaData.page…

cc7f529

…Param to pageParamKey only when it is defined

marcmll approved these changes Nov 2, 2022

View reviewed changes

saihaj approved these changes Nov 3, 2022

View reviewed changes

wileymc mentioned this pull request Nov 3, 2022

react-query plugin with graphql-request fetcher generates invalid infinite query if query has no arguments dotansimha/graphql-code-generator-community#227

Open

saihaj merged commit af40efb into dotansimha:master Nov 4, 2022

github-actions bot mentioned this pull request Nov 4, 2022

Upcoming Release Changes #8573

Merged

charlypoly added a commit to dotansimha/graphql-code-generator-community that referenced this pull request Nov 7, 2022

backport dotansimha/graphql-code-generator#8567

aee5a7a

jpb06 mentioned this pull request Nov 26, 2022

chore: infinite query for products list jpb06/graphql-shop#9

Merged

EandrewJones mentioned this pull request Nov 28, 2022

revert PR #8497: "fixes issue #7549" dotansimha/graphql-code-generator-community#25

Merged

10 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hotfix for typescript react query infinite query breaking change #8567

Hotfix for typescript react query infinite query breaking change #8567

EandrewJones commented Nov 2, 2022

changeset-bot bot commented Nov 2, 2022

marcmll left a comment

EandrewJones commented Nov 3, 2022 via email

wileymc commented Nov 3, 2022

saihaj commented Nov 4, 2022

wileymc commented Nov 5, 2022

EandrewJones commented Nov 5, 2022 via email

wileymc commented Nov 5, 2022

EandrewJones commented Nov 5, 2022 via email

wileymc commented Nov 6, 2022 via email

EandrewJones commented Nov 8, 2022 •

edited

wileymc commented Nov 8, 2022 •

edited

EandrewJones commented Nov 8, 2022 •

edited

blaenk commented Nov 10, 2022

EandrewJones commented Nov 10, 2022

wileymc commented Nov 10, 2022

Type Mismatch

Fix for the broken calls

EandrewJones commented Nov 10, 2022

StampixSMO commented Nov 21, 2022

EandrewJones commented Nov 21, 2022

blaenk commented Nov 21, 2022

wileymc commented Nov 22, 2022

EandrewJones commented Nov 22, 2022

blaenk commented Nov 22, 2022

EandrewJones commented Nov 24, 2022

hwennnn commented Jan 16, 2023

EandrewJones commented Jan 16, 2023

blaenk commented Jan 17, 2023

EandrewJones commented Jan 17, 2023 via email

blaenk commented Jan 17, 2023

EandrewJones commented Jan 17, 2023 via email

Hotfix for typescript react query infinite query breaking change #8567

Hotfix for typescript react query infinite query breaking change #8567

Conversation

EandrewJones commented Nov 2, 2022

Description

Type of change

How Has This Been Tested?

Checklist:

changeset-bot bot commented Nov 2, 2022

🦋 Changeset detected

marcmll left a comment

Choose a reason for hiding this comment

EandrewJones commented Nov 3, 2022 via email

wileymc commented Nov 3, 2022

saihaj commented Nov 4, 2022

wileymc commented Nov 5, 2022

EandrewJones commented Nov 5, 2022 via email

wileymc commented Nov 5, 2022

EandrewJones commented Nov 5, 2022 via email

wileymc commented Nov 6, 2022 via email

EandrewJones commented Nov 8, 2022 • edited

wileymc commented Nov 8, 2022 • edited

EandrewJones commented Nov 8, 2022 • edited

Type Mismatch

Fix for the broken calls

blaenk commented Nov 10, 2022

EandrewJones commented Nov 10, 2022

wileymc commented Nov 10, 2022

Type Mismatch

Fix for the broken calls

EandrewJones commented Nov 10, 2022

StampixSMO commented Nov 21, 2022

EandrewJones commented Nov 21, 2022

blaenk commented Nov 21, 2022

wileymc commented Nov 22, 2022

EandrewJones commented Nov 22, 2022

blaenk commented Nov 22, 2022

EandrewJones commented Nov 24, 2022

hwennnn commented Jan 16, 2023

EandrewJones commented Jan 16, 2023

blaenk commented Jan 17, 2023

EandrewJones commented Jan 17, 2023 via email

blaenk commented Jan 17, 2023

EandrewJones commented Jan 17, 2023 via email

EandrewJones commented Nov 8, 2022 •

edited

wileymc commented Nov 8, 2022 •

edited

EandrewJones commented Nov 8, 2022 •

edited