SignTypedData failed with "A generic request processing error has occurred"

Description of the issue:
I’m using ethers v5.7.2 to send request eth_signTypedData_v4 to request message sign to connected wallet

Here is the code I’ve been using for requesting this signature

import { Web3Provider } from '@ethersproject/providers'

const typedData = {
  types: {
    'Hubble Exchange': [
      { name: 'action', type: 'string' },
      { name: 'notice', type: 'string' },
      { name: 'chainId', type: 'string' },
      { name: 'nonce', type: 'int' },
    ],
  },
  domain: { name: 'Hubble Exchange', version: 'v2', chainId: 1 },
  primaryType: 'Hubble Exchange',
  message: {
    action: 'Hey sign this message',
    notice: 'Only sign this on example.com',
    chainId: '1',
    nonce: 0,
  },
}

const signer = (new Web3Provider(window.ethereum)).getSigner()

const signature = await signer._signTypedData(
  typedData.domain,
  typedData.types,
  typedData.message
)

Here is the error I get from brave wallet

{code: 4200, message: 'A generic request processing error has occurred'}

For reference ethersjs sends eth_signTypedData_v4 request

async _signTypedData(domain: TypedDataDomain, types: Record<string, Array<TypedDataField>>, value: Record<string, any>): Promise<string> {
        // Populate any ENS names (in-place)
        const populated = await _TypedDataEncoder.resolveNames(domain, types, value, (name: string) => {
            return this.provider.resolveName(name);
        });

        const address = await this.getAddress();

        try {
            return await this.provider.send("eth_signTypedData_v4", [
                address.toLowerCase(),
                JSON.stringify(_TypedDataEncoder.getPayload(populated.domain, types, populated.value))
            ]);
        } catch (error) {
            if (typeof(error.message) === "string" && error.message.match(/user denied/i)) {
                logger.throwError("user rejected signing", Logger.errors.ACTION_REJECTED, {
                    action: "_signTypedData",
                    from: address,
                    message: { domain: populated.domain, types, value: populated.value }
                });
            }
            throw error;
        }
    }

Is the issue occurring on a specific network?
no

What operating system are you using?
MacOS

Brave Version (check About Brave):
Version 1.61.104 Chromium: 120.0.6099.115 (Official Build) (arm64)

Additional Information:

I see in your example that version is set to ‘v2’ should this be ‘v4’?

Here are the official docs for how to sign with window.ethereum

Is there a difference in using signer._signTypedData vs signer.signTypedData https://docs.ethers.org/v6/api/providers/#Signer-signTypedData?

Can you explain how it is set to ‘v2’ in above example?

There is no diff using signer._signTypedData vs signer.signTypedData
the one with _ is from ethers v5.7.2 (they added _signTypedData to be backward compatible for signTypedData and also support ‘v4’ with _[underscore] version)

Hey, please help me debug this.

I ran your code locally and found the issue.

the “type” for nonce should be not be “int”.

changing to “uint256” worked for me

const typedData = {
      types: {
        'Hubble Exchange': [
          { name: 'action', type: 'string' },
          { name: 'notice', type: 'string' },
          { name: 'chainId', type: 'string' },
          { name: 'nonce', type: 'uint256' },
        ],
      },
      domain: { name: 'Hubble Exchange', version: 'v2', chainId: 1 },
      primaryType: 'Hubble Exchange',
      message: {
        action: 'Hey sign this message',
        notice: 'Only sign this on example.com',
        chainId: '1',
        nonce: 0,
      },
    };

For reference:

From https://eips.ethereum.org/EIPS/eip-712
Definition : The atomic types are bytes1 to bytes32 , uint8 to uint256 , int8 to int256 , bool and address . These correspond to their definition in Solidity. Note that there are no aliases uint and int . Note that contract addresses are always plain address . Fixed point numbers are not supported by the standard. Future versions of this standard may add new atomic types.