Connecting oisy-wallet-signer `Uncaught TypeError: (void 0) is not a function`?

[AliSci]

@dfinity_oisy-wallet-signer_icrc-wallet.js?v=54cdd1a5:8434 Uncaught TypeError: (void 0) is not a function
    at s2 (@dfinity_oisy-wallet-signer_icrc-wallet.js?v=54cdd1a5:8434:84)
    at @dfinity_oisy-wallet-signer_icrc-wallet.js?v=54cdd1a5:8442:10
var s2 = ({ additionalProtocols: e2 = [], allowHttpLocally: l = true }) => (void 0)().refine((n) => {
error at ().refine((n) => {

import { IcrcWallet } from "@dfinity/oisy-wallet-signer/icrc-wallet";
......


const url =
    import.meta.env.VITE_DFX_NETWORK === "ic"
      ? "https://oisy.com/sign"
      : "https://staging.oisy.com/sign";

  const host =
    import.meta.env.VITE_DFX_NETWORK === "local"
      ? import.meta.env.VITE_IC_HOST // "http://localhost:4943"
      : "https://ic0.app";


const walletInstance = await IcrcWallet.connect({
        url,
        host,
        onDisconnect: () => {
          setIsConnected(false);
          setAccount(null);
          setWallet(null);
        },
      });

....

packages dep

"@dfinity/agent": "^2.4.1",
    "@dfinity/auth-client": "^2.4.1",
    "@dfinity/candid": "^2.4.1",
    "@dfinity/identity": "^2.4.1",
    "@dfinity/identity-secp256k1": "2.3.0",
    "@dfinity/ledger-icrc": "^2.9.1",
    "@dfinity/llm": "^1.1.1",
    "@dfinity/oisy-wallet-signer": "^0.2.3",
    "@dfinity/principal": "^2.4.1",
    "@dfinity/utils": "^2.13.2",
    "@dfinity/zod-schemas": "^2.0.0",
"zod": "^3.23.8"
```

[StefanBerger-DFINIT1]

Hi @AliSci
We will look into this as soon a possible. Meanwhile, did you check the source code of the relying party of the demo app inside the oisy wallet signer?
You might find a good pattern on how to initiate the connection to an icrc-wallet. (specifically the Connect.svelte in the lib)

oisy-wallet-signer/demo/src/relying_party_frontend at main ·...

[peterparker]

@AliSci

"@dfinity/zod-schemas": "^2.0.0",

There’s a bit of an inconvenient situation right now with the zod-schemas. Zod rolled out v4, which is used in the latest schema, but since not all dependencies have migrated to it yet, we’re currently dealing with two versions.

I’m not entirely sure, but I believe the issue you’re encountering might be caused by this incompatibility. Long story short—could you try downgrading @dfinity/zod-schemas to version 1.0.0 and see if that helps?

npm rm @dfinity/zod-schemas && npm i @dfinity/zod-schemas@1.0.0

[peterparker]

I’m not entirely sure, but I believe the foundation generally recommends using Identity Kit. I’m not sure if it’s still “only” supported for React or if it supports now other frameworks. Many dapps are using it, so it’s probably worth a shot.

Unrelated — if you try out the suggestion I mentioned above, please let me know. I’d be curious to see whether that was the issue or if it’s something else.

[AliSci]

@dfinity_oisy-wallet…t.js?v=148a3076:535 Uncaught (in promise) j2: The request sent by the relying party is not supported by the signer.
at r2.handleErrorMessage (http://localhost:5173/node_modules/.vite/deps/@dfinity_oisy-wallet-signer_icrc-wallet.js?v=148a3076:535:75)
at U (http://localhost:5173/node_modules/.vite/deps/@dfinity_oisy-wallet-signer_icrc-wallet.js?v=148a3076:459:21)

[peterparker]

This one is a bit harder to diagnose based on the stack trace alone. Is your dapp open source? If so, could you share a link to the branch, or perhaps share some additional code?

–

Unrelated side note: We just released a new version of the @dfinity/oisy-wallet-signer library, which explicitly pins zod-schemas to version 1.0.0 instead of using ^1.0.0. This should prevent others from encountering the same issue you ran into earlier.

[AliSci]

here is my full code

import { useState, useCallback } from "react";
import { Principal } from "@dfinity/principal";
// import {IcpWallet} from '@dfinity/oisy-wallet-signer/icp-wallet';
import { IcrcWallet } from '@dfinity/oisy-wallet-signer/icrc-wallet';

export async function depositWithOisy(amount:number,user:Principal){

  const url =
      import.meta.env.VITE_DFX_NETWORK === "ic"
        ? "https://oisy.com/sign"
        : "https://staging.oisy.com/sign";

    const host =
      import.meta.env.VITE_DFX_NETWORK === "local"
        ? import.meta.env.VITE_IC_HOST // http://localhost:4943
        : "https://ic0.app";

  console.log({url, host})
  const walletInstance = await IcrcWallet.connect({
        url,
        host,
        onDisconnect: () => {
          console.log("disocneted")
        },
      });

      const { allPermissionsGranted } =
        await walletInstance.requestPermissionsNotGranted();

      if (!allPermissionsGranted) {
        throw new Error("All permissions are required to continue");
      }

      const accounts = await walletInstance.accounts();
      const userAccount = accounts?.[0] || null;

      if (!userAccount) {
        throw new Error("The wallet did not provide any account");
      }

      const res = await walletInstance.approve({
        owner: userAccount.owner,
        params: {
          spender: {
            owner: Principal.fromText(userAccount.owner),
            subaccount: [],
          },
          amount: BigInt(amount),
        },
        ledgerCanisterId:  import.meta.env.VITE_CANISTER_ID_CKUSDC_LEDGER,
      });
      console.log({res})

      const result = await walletInstance.transferFrom({
          ledgerCanisterId: import.meta.env.VITE_CANISTER_ID_CKUSDC_LEDGER,
          owner: userAccount.owner,
          params: {
            from: {
              owner: Principal.fromText(userAccount.owner),
              subaccount: [],
            },
            to: {
              // owner: Principal.fromText(
              //   import.meta.env.VITE_BACKEND_CANISTER_ID,
              // ),
              owner: user,
              subaccount: [],
            },
            amount: BigInt(amount),
          },
        });
        console.log({result})
}

[peterparker]

@peterparker

supported for React or if it supports now other frameworks.

Oh, I forgot to mention earlier that Identity Kit is, I believe, using signer-js under the hood. So, if you’re not using React — and assuming it’s still required for the kit — you can try using this library directly instead which is itself agnostic.

[AliSci]

I will check tomorrow. In the meantime, can you check that depositWithOisy?

[peterparker]

@AliSci

can you check that depositWithOisy?

I’m doing it literally as we speak.

[peterparker]

I was able to replicate the same issue using your code.

@dfinity_oisy-wallet-signer_icrc-wallet.js?v=dc18f2f1:530 Uncaught (in promise) j2: The request sent by the relying party is not supported by the signer.

In my case, I encountered the issue because import.meta.env.VITE_CANISTER_ID_CKUSDC_LEDGER was undefined.

Can you double check if this environment variable is defined in your app?

–

const res = await walletInstance.approve({
			owner: userAccount.owner,
			params: {
				spender: {
					owner: Principal.fromText(userAccount.owner),
					subaccount: [],
				},
				amount: BigInt(amount),
			},
undefined --->	ledgerCanisterId:  import.meta.env.VITE_CANISTER_ID_CKUSDC_LEDGER,
		});

[AliSci]

no it seems to work just fine and it show me checkmark the transaction is done
After deposit $100 or to the user principal

When I check the palace of the user from the CKSDC ledger it shows zero

However, when I try

dfx canister --identity minter call ckusdc_ledger icrc1_transfer “(record {to = record { owner = principal "$ user_principal"; }; amount = 100_000_000; })”

It worked just fine
When I checked the palace, I got right

[peterparker]

Not sure why you’re mentioning “$100” and “palace” — I assume those are typos for 100 ckTESTUSDC and balance, is that right?

Also, I’m not sure what you mean by “When I check the palace of the user from the CKUSDC ledger it shows zero”. How exactly are you checking the balance? Through your frontend? Are you sure both are pointing to the same network, not one on mainnet and the other locally? Are the ICRC account details you’re using for the calls exactly the same?

In addition, if you’re referring to the code you shared yesterday, note that it was an ICRC approve call, not a transfer as displayed in your DFX command. An approval does not credit or debit any tokens, so the balance remains unchanged. Could that be the confusion?

[AliSci]

this is how i check balance const balanceResult = await ckUSDCActor?.icrc1_balance_of({ owner: Principal.fromText(userPrincipal), subaccount: [], });
yes i also use i mean cktestusdc

[peterparker]

Sounds correct. Maybe the confusion is related to using approve, as I mentioned above?

If not, it’s a bit hard to debug as-is. But if you can provide a minimal sample repo to reproduce the issue, I’d be happy to take a look.

[AliSci]

@peterparker

ckTESTUSDC

I will make one on icp.ninja. ICP Ninja

it is not ready yet maybe I will finish it later.
, However, our code is on oDoc/src/frontend/pages/walletPage/index.tsx at 515b11c72fb3e062c1f279e1dc5ca1b562177d31 · aliscie2/oDoc · GitHub
I don’t recommend to run it, it is not very quick but it has make deploy-all

However, I noticed it shows ckUSDC not ckTESTUSDC

This is how i install it

dfx deploy ckusdc_ledger --argument "(variant {
  Init = record {
    decimals = opt 6;
    token_symbol = \"ckUSDC\";
    token_name = \"ckUSDC\";
    transfer_fee = 10_000;
    metadata = vec {};
    minting_account = record { owner = principal \"$MINTER_PRINCIPAL\"; };
    initial_balances = vec {};
    archive_options = record {
      num_blocks_to_archive = 1000;
      trigger_threshold = 2000;
      max_message_size_bytes = null;
      cycles_for_archive_creation = opt 100_000_000_000_000;
      node_max_memory_size_bytes = opt 3_221_225_472;
      controller_id = principal \"2vxsx-fae\"
    };
    max_memo_length = opt 80;
    feature_flags = opt record { icrc2 = true };
  }
})" --mode=reinstall -y


```


https://github.com/aliscie2/oDoc/blob/dev2/scripts/deploy_ledger.sh

[peterparker]

@AliSci

However, our code

I had a look at your code here and noticed that you are using transferFrom, which is the function to call after an approval.

Is that correct? Are you trying to implement an approve/transferFrom pattern, and was the approval granted beforehand?

@AliSci

I noticed it shows ckUSDC not ckTESTUSDC

I’m a bit confused. The screenshot you shared shows a request from localhost:5173 on staging.oisy.com, but you’re mentioning a dfx deploy command.

Are you perhaps testing with a local frontend connected to a local replica, while trying to approve a sign message using OISY running on mainnet? Could that be true and if yes, probably an issue?

[AliSci]

I just want to test the user make a deposit, “localy”. I think I did it wrong, staging does not work with localhost, right? i should run oisy locally ?

[AliSci]

@peterparker

an

We can’t do it on https://icp.ninja/ ?

[peterparker]

@AliSci

staging does not work with localhost, right? i should run oisy locally ?

Correct. OISY staging (on mainnet) does not work if you want to test your frontend with other canisters and a replica running locally.

I’m not sure how easy it is to set up OISY to run locally nowadays, but literally last week I documented in the README how to run the pseudo Wallet — which we use for E2E testing of the signer — locally.

If you wish to test locally, maybe you can give it a try?