Looking for help to trouble shoot the error below. I am trying to mint an ERC721 nft on the Matic Testnet. I am using hardhat and have tried the following tesntnet networks that gave me the same error:
https://matic-mumbai.chainstacklabs.com
https://rpc-mumbai.maticvigil.com
https://polygon-mumbai.g.alchemy.com/v2/
I was able to successfully deploy my ERC721 smart contract on the Matic Testnet. But when I tried minting the NFT I ran into the following error:
(node:53836) UnhandledPromiseRejectionWarning: Error: Network doesn't support eip-1559
at /Users/gravitywaves/Projects/mynft2/node_modules/web3-eth-accounts/lib/index.js:323:35
at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:53836) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:53836) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
I'm taking a wild guess here, but you might be including maxFeePerGas in your transaction, which is how transactions should be sent according to EIP-1559. AFAIK (I might be wrong) Polygon hasn't implemented EIP-1559 yet.
Try chaing maxFeePerGas for gasPrice in your transaction. I was experiencing the exact same error and that's what worked for me.
Also, in my case I was able to send transactions to the deployed contract through Remix, so I was sure there was something wrong with my code. You might want to run the same check.
Related
It's a weird bug that I am experiencing.
My test fails due to a detached element from DOM(this is not the issue) and it auto-triggers a retry since I have retries enabled and set the number of attempts to 2.
However, as soon as cypress begins executing the second attempt, I am getting the following uncaught exception.
The point is, cypress passes the test where the uncaught exception occurred during the second attempt.
It's causing me to believe that the tests have passed, whereas, in reality, no cypress commands were executed during the second attempt.
I am unable to reproduce this in any other code, and unfortunately, cannot share the scripts due to company policy.
Any tips, resolution, debug guidance here would be helpful.
We use EventStore 5.0.0 and we faced with the following situation:
when we store event, sometimes, C# client receives response with error. Error from log:
EventStore.ClientAPI.Exceptions.WrongExpectedVersionException: Append failed due to WrongExpectedVersin. Stream: QWE.Api.SomeClassifier.Actors.ProductInfoActors.ProductActor-q5839583-5r82-5k30-sl13-1t485329g395, Expected version: 13, CurrentVersion:14
Disregard this response with error, event is stored with version 14.
What could it be the reason of this error message, while event was really stored?
We think the problem is in slow ssd, or high load.
This is the database built-in optimistic concurrency check. You can find more about it here: https://developers.eventstore.com/clients/grpc/appending-events/#handling-concurrency
I have an indy IDHTTP component which is called repeatedly using a timer (4-5 times a second)
I have a poor internet connection so occasionally there are timeout problems or garbage responses that cause an error with the idHTTP component.
I have a try except finally clause around the component but when an error occurs the code shows an error and execution stops.
I know what causes the errors, its my poor internet connection, but what i want to do is just ignore the invalid response or error and just continue so that my program doesn't break.
I'm getting these errors because of a poor internet connection, I can't fix that. The code is used to access the Betfair API so advising Betfair won't help.
Is it OK to panic() when failed to create AWS session?
As an opposite, I can just return the error from my handler function (in this case I have to create the session in the handler code, but not in the init()).
The docs say
Lambda will re-create the function automatically
Does it mean the panic always causes the cold-start and is preferred to return error from the handler?
Yes. A panic will trigger a cold restart of your code. The use of panic should be reserved for exceptional circumstances; returning an error is to be preferred in most circumstances.
The answer depends on what is going on in init section.
If you create session clients to connect to other services it might be good to panic and cause cold-start than continue container's lifecycle with the failed clients.
Our applications are using the odbc driver to access an Impala database. We've discovered that in certain difficult-to-replicate situations, the driver will trigger a segfault within its cgo code, which manifests as a fatal error once it propagates back up through the driver and to our code. Since we want some cleanup and alerting to happen in these situations, I implemented a deferred panic catcher, hoping this might catch them.
However, it isn't working. The fatal error continues straight past the deferred function containing the recover() call (so apparently it's not a panic, despite the print output looking similar), though it does catch other panics. A github issue suggests that cgo signals cannot be caught, and that applications should gracelessly and immediately crash if one occurs. This is an unacceptable crash case for our production applications, so I'm wondering if that's changed in the last 6 years, or if anyone knows of another way of running some cleanup code in the event of a cgo signal. It seems like extremely poor design to have no way at all catch and handle these fatal errors.