Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Odd caching when wallet updates? #5977

Open
314159265359879 opened this issue Nov 19, 2024 · 4 comments
Open

Odd caching when wallet updates? #5977

314159265359879 opened this issue Nov 19, 2024 · 4 comments
Labels
bug Functionality broken bug-p4 Non-critical functionality broken for few users, or there are clear workarounds extension

Comments

@314159265359879
Copy link
Contributor

Does the wallet cache stuff between versions?
What about the user session in local storage would cause that considering we've called disconnect() etc?

These questions were posted by a dev after encountering this issue while connecting to devnet:

They say this was working fine less then a month ago and now they see this error "contract not found" using local devnet:
we're seeing some issues with stacks/connect locally with devnet and wondering if anyone has any info on what might be causing it.

despite being connected to devnet, with the network specified as devnet, we get this error saying that the contract cannot be found.

Image

They solved it by:

  • we ported wallet to new browser session
  • so it's caching in localstorage
  • cleared local storage
  • problem solved

More details on the exact call:

It's definitely deployed correctly to devnet. all of the rpc ready only calls we're making are functioning. it seems to be limtied to when we interact with the contract through stacks connect, via the wallet. in this case leather.
Image
"@stacks/connect": "^7.9.0",
"@stacks/network": "^7.0.2",
"@stacks/transactions": "^7.0.2",
bobby and i are stumped.
this worked fine a while ago
now we just can't get it to interact with the contract

the code they use to call the contract

const txOptions: ContractCallOptions = {
      network: network,
      anchorMode: AnchorMode.Any,
      contractAddress: contractAddress,
      contractName: contractName,
      functionName: "mint",
      functionArgs: [uintCV(mintAmount)], // Pass mint quantity directly
      postConditionMode: PostConditionMode.Deny,
      postConditions: postConditions,
      userSession: userSession,
      onFinish: (response: FinishedTxData) => {
        console.log(response);
        onMintSuccess(response);
      },
      onCancel: () => {
        console.log("cancelled");
      },
    };

    try {
      await openContractCall(txOptions);
    } catch (err) {
      console.error("Mint failed", err);
      setError("Minting failed. Please try again.");
    } finally {
      setMinting(false);
    }
  };

They used similar code for a recent project and it worked without issue and now they were seeing this. I suspected a disconnect between the dapp and extension wallet. Which proved the problem. And I have seen issues like this come up in the past when testing other dapps and switching networks (and perhaps getting wallet updates). I have never thought the issue could be caused by automatic wallet extension updates though. Hence me posting this here.

@314159265359879 314159265359879 added the bug Functionality broken label Nov 19, 2024
Copy link

linear bot commented Nov 19, 2024

@314159265359879
Copy link
Contributor Author

Possible solution for better handling of network used by dapp and Leather: #4194

@kyranjamie
Copy link
Collaborator

Regarding API cache, we clear this when there's a app version, I think it's unrelated to cache.

I do see he's using the latest version of stacks js though, v7. So perhaps there's an issue there?

Copy link
Collaborator

camerow commented Nov 21, 2024

The wallet wouldn't cache things between versions per-se. Any app running has a browser context in which it is assigned storage mechanisms, and HTTP headers / cookies / local storage are all applied to that context. The caches and storage have no concept of a version of the application.

I don't see this as a priority for us right now, especially considering they could fix their issue and I don't see any reproducible steps

@314159265359879 314159265359879 added the bug-p4 Non-critical functionality broken for few users, or there are clear workarounds label Nov 21, 2024
@camerow camerow added the extension label Jan 7, 2025 — with Linear
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Functionality broken bug-p4 Non-critical functionality broken for few users, or there are clear workarounds extension
Projects
None yet
Development

No branches or pull requests

3 participants