Signing Transaction yields invalid request error

[samir-85]

While, previously Spacesuite has worked fine for me, I have the following problem since updating the plugin.

First of all web3.eth.getAccounts(console.log) returns all 10 accounts, so Spacesuite is correctly detecting the nano ledger.

Executing the transaction of my smart contract via contract.methods.mymethod(param).send() returns the following InternalError: message: Invalid request code: -32603

When executing the same code with Metamask, there are no problems.

Dou have any clue what is going on and if this related to the new SpaceSuite release?

[jamespic]

Hmm.. I feared something like this might happen.

The latest release contains a workaround for a race condition in MakerDAO Dai dashboard, which makes it aggressively cache the address list. It shouldn't have affected signing code, but it might mean that connectivity issues are masked until you come to sign a transaction. Or it could be affecting signing in ways I hadn't though of.

If this is a dapp that's currently publicly available, you can send me a link, and I'll see if I can reproduce the issue.

If it's a dapp that isn't yet public, it would be help narrow down the issue if you could either post a snippet that reproduces the issue, or enable Debug from the Options screen, reproduce the issue, then send me over a copy of the developer console output.

It might also be useful to know whether the problem still occurs when you disable "Use Hacks" from the options, since this would disable the aforementioned MakerDAO workaround (although it may also disable other MetaMask compatibility hacks that you may have been relying on).

[samir-85]

Indeed, disabling Use Hacks resolves the problem.

Unfortunately, this occurs in a private Dapp connected a private Parity node.

Here's the web3 1.0 code snippet where the problem is occuring. Basically, it happens when executing a smart contract transaction. Let me know if I can help with providing any other information.

I also want to mention that calling smart contract methods is working. So the general connectivity to the Parity node does work, the problem only occurs when executing smart contract transactions.

`import Web3 from 'web3' import TANValidator from './contracts/TANValidatorExtended.json'

let provider = window.web3.currentProvider; let web3 = new Web3(provider);

web3.eth.getAccounts().then(accounts => { console.log("accounts" + accounts); let contract = new web3.eth.Contract( TANValidator.abi, "0xEddA486ddB7eaa8f9FEce8c682EFD40f535b3Ad5", {from: accounts[0]}); return contract.methods.authenticate(someparams).send().on('receipt', function(receipt) { // bla bla doing some stuff }).on("error", function(error) { // when executing the transaction with spacesuite it always jumps into this error section console.log(error); });`

[jamespic]

@samir-85 OK, I'll spin up a private Parity node and see if I can reproduce the issue. It would still be useful to get a copy of the logs from running it in debug mode, if that's feasible.

Also, one other thing that might sound crazy, but would be really useful diagnostically: Do you still have the problem if you leave the page open for 60 seconds, and then make the call? Account lists and network ids are cached, and polled for updates every 60 seconds. I know this was a pain for me when developing the caching changes, but I figured I was probably the only user who was changing the network setting frequently enough for this to be an issue. It should be a fairly easy fix, if so.

[samir-85]

James, actually right now I'm not able to reproduce anymore. Even with disable hacks it is working .

Sorry for all the confusion - I spend many hours on debugging this problem and now it is magically gone.

I will let you know when I'm able to reproduce it again.

Cheers.

[jamespic]

No worries. In the meantime, I'll tweak the cache invalidation logic - I suspect this is what was causing your issues, and it could definitely be improved.

[jamespic]

I've just pushed version 0.2.6, which should make it less flaky if you're switching between network configs, and should make cache invalidation more predictable. Please let me know if you have any further problems.

I'm really sorry about making you spend hours tracking down this bug, only for it to disappear.