metamask-extension

metamask-extension copied to clipboard

Sentry Issue: METAMASK-X7W2

Error: The method does not exist / is not available.
  at new JsonRpcError (node_modules/@metamask/rpc-errors/dist/classes.js:24:1)
  at getJsonRpcError (node_modules/@metamask/rpc-errors/dist/errors.js:176:1)
  at exports.rpcErrors.methodNotFound (node_modules/@metamask/rpc-errors/dist/errors.js:35:1)
  at checkForHttpErrors (node_modules/@metamask/eth-json-rpc-middleware/dist/fetch.js:80:1)
  at <anonymous> (node_modules/@metamask/eth-json-rpc-middleware/dist/fetch.js:47:1)
...
(1 additional frame(s) were not displayed)

This log message should have more detail about which method is not available. From the sentry issue, it's unclear whether this is indeed an error or should just be a warning or informational item.

Re-assigning to Shared Libraries for further assessment. If its found to be an issue with a dapp-facing API issue, then please assign back to us.

Full stack trace:

Error#176: PollingBlockTracker - encountered an error while attempting to update latest block:
{
  "code": -32601,
  "message": "The method does not exist / is not available.",
  "stack": "Error: The method does not exist / is not available.\n    at new o (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:433448)\n    at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:436553)\n    at Object.methodNotFound (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:437113)\n    at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:24534)\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:25845\n    at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:193619"
}
  at new o (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:433448)
  at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:436553)
  at Object.methodNotFound (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:437113)
  at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:24534)
  at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:25845
  at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:193619
{
arguments: [
Error#176:, 
PollingBlockTracker - encountered an error while attempting to update latest block:
{
  "code": -32601,
  "message": "The method does not exist / is not available.",
  "stack": "Error: The method does not exist / is not available.\n    at new o (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:433448)\n    at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:436553)\n    at Object.methodNotFound (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:437113)\n    at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:24534)\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:25845\n    at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:193619"
}
  at new o (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:433448)
  at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:436553)
  at Object.methodNotFound (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:437113)
  at a (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:24534)
  at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-0.js:7:25845
  at async chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-0.js:1:193619
], 
logger: console
}

@desi Look for old ticket around this and mark as duplicate once we do.

^ That was a suggestion I made, as I thought this sounded similar to another issue. But I had a look and was unable to find it, so maybe we can't close this as a dupe after all.

hello. please explain what it is about? what should I do and what is this topic anyway?

It seems like this error would be caused by a user inputting an invalid RPC URL (one that doesn't support eth_blockNumber).

One problem here is that this type of failure should never land in Sentry. But another problem is that the block tracker shouldn't be continuously polling after it encounters an error that we expect to persistently fail.

For that second issue, I wonder if there is a way for the block tracker to indicate that it's in an invalid state (i.e. that polling was stopped).

Main issue is that we aren't catching the error and because we aren't catching the error it is showing up in sentry but it shouldn't be.

The second issue is covered in the tech debt doc. Mark will amend the tech debt doc to make sure that case is considered.

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

Sentry Issue: METAMASK-XCG3

Maybe something like this would make sense:

• Update block tracker to stop (and stay stopped) when this error is encountered
• Have the block tracker emit an error event
• Listen for that event in the NetworkController network client, and set the status of that network as failed
• Show an error modal to the user when the status is changed to failed, asking them to switch networks/RPC endpoints

This ticket may be partially solved by https://github.com/MetaMask/eth-block-tracker/issues/311 (in the case where the block tracker is stopped).

In addition, since this ticket was created we have added automatic retries for each request via RpcService. In light of this, perhaps we should consider automatically turning off the block tracker if we emit the rpcServiceUnavailable event (which occurs if the maximum number of consecutive failures is exceeded). We can also consider changing the status of the network to unavailable as Mark mentioned.

Both of these feel like separate tickets to me if this is the route we want to take, however.

Taking a closer look at:

• Update block tracker to stop (and stay stopped) when this error is encountered

I hesitate to do this because how long do we keep it stopped? It seems like the circuit breaker pattern that we have now will take care of preventing requests if we know that an endpoint is unavailable.

Instead I wonder if the block tracker should be smarter and not attempt to make any requests to a network until we've confirmed that the network is available? Or maybe that's something that happens at an RPC service level, since it's the RPC service that keeps track of that. Maybe RpcServiceChain looks something like:

  #availability?: DeferredPromise;

  // ...

  async request<Params extends JsonRpcParams, Result extends Json>(
    jsonRpcRequest: JsonRpcRequest<Params>,
    fetchOptions: FetchOptions = {},
  ): Promise<JsonRpcResponse<Result | null>> {
    if (this.#availability) {
      await this.#availability.promise;
    }

    this.#availability = createDeferredPromise();
    const response = await this.#services[0].request<Params, Result>(
      jsonRpcRequest,
      fetchOptions,
    );
    this.#availability.resolve();
    return response;
  }

For:

• Listen for that event in the NetworkController network client, and set the status of that network as failed
• Show an error modal to the user when the status is changed to failed, asking them to switch networks/RPC endpoints

Perhaps we can consider this:

• Add an onFirstSuccessfulRequest hook to RpcServiceChain. We would fire this event at the same time as resolving the "availability" promise above, with at least the chain ID of the endpoint.
• Listen to onFirstSuccessfulRequest in NetworkClient and publish a NetworkController:rpcEndpointAvailabilityConfirmed event.
• Have NetworkController listen for this event and update the status of the chain in state to available.
• Similarly, have NetworkController listen for NetworkController:rpcEndpointUnavailable and set the status of the chain to unavailable.

Coming back to this ticket and Sentry error though... I am looking on Sentry and the only instance where I see this is here: https://metamask.sentry.io/issues/6580585858/events/90ce914fa59e487aa6ed4cdc1cef7c17/. This seems to be happening in Snaps and not somewhere else.

Given this I am inclined to close this ticket and open more tickets for the suggestions above. Anyone disagree...?