Mutations not invalidating cache when sending a mutation with data containing a hashtag (#)

[FPDK]

Hi,

This issue seems to be related to #195

If I send this mutation the first time, everything is OK:

mutation updateItem {
    updateItem(input: {
        id: "path/to/1",
        name: "URQL example #1",
        comment:"Hello world"
    }) {
        item {
            id
        }
    }}

But if I then change only the name to URQL example#2 and send the mutation again, then the old mutation is sent.

The new mutation shows up if I console.log my mutation before calling my URQL client:

console.log(mutation) // This outputs the new mutation (changed name)
client
            .mutation(mutation)
            .toPromise()
            .then((response) => {
...
})

A new mutation is sent if:

• Another property is changed as well (name: "URQL example #2", comment: "Hello github")
• The content before the hashtag is changed (name: "Something before the hashtag#and after")

I have set up my client as follows:

const client = createClient({
    url: API_GRAPHQL_URL,
    requestPolicy: "network-only",
    exchanges: [
        devtoolsExchange,
        dedupExchange,
        fetchExchange,
    ],
    fetchOptions: () => {
        return {
            credentials: "include",
            headers: {},
            cache: "no-cache",
        }
    },
})

My temporary fix is to always change another property in the mutation (append a space to the "comment" in the above case).

I am using [email protected] on Typescript [email protected].

[JoviDeCroock]

Mind making a reproduction? The client you linked is not using a cache so that could be the issue 😅

EDIT: Oh I realise now you are inlining your variables 😅 to avoid having this happen we'd advise you to use interpolation

[kitten]

This is technically a duplicate of #1960 and we weren't too inclined to make this more complicated when this is more of an uncommon behaviour due to the lack of variables in the query. It also leads to degraded behaviour rather than straight up breakage, but we could update the regex here too