miningcore icon indicating copy to clipboard operation
miningcore copied to clipboard

[E] [PayoutManager] [eth1] Payment processing failed System.InvalidOperationException: This NpgsqlTransaction has completed; it is no longer usable.

Open James1847 opened this issue 2 years ago • 5 comments

For now, I can mine the block in Ethereum Ropsten Network, but when the miningcore execute the PPLNS payment process for the miners, it can't send ether to miner address, always shows the ERROR below: image I use geth --ropsten --datadir=/www/data --snapshot=false --cache=21000 --maxpeers=250 --txpool.globalslots=1000 --http --http.port=8545 --http.api=eth,net,web3,miner -ws --ws.port=8546 --ws.api=eth,net,web3,miner --keystore='/www/.ethereum/keystore' --unlock='0xDD1de78b63dE187304E709bE4A75842700bEd940' --password='/www/password' --allow-insecure-unlock --miner.etherbase='0xDD1de78b63dE187304E709bE4A75842700bEd940' --mine --miner.threads=0 to start the geth, and use the following config.json in miningcore:

{ "logging": { "level": "info", "enableConsoleLog": true, "enableConsoleColors": true, "logFile": "", "logBaseDirectory": "", "perPoolLogFile": false }, "banning": { "manager": "Integrated", "banOnJunkReceive": true, "banOnInvalidShares": false }, "notifications": { "enabled": false, "email": { "host": "smtp.example.com", "port": 587, "user": "user", "password": "password", "fromAddress": "[email protected]", "fromName": "support" }, "admin": { "enabled": false, "emailAddress": "[email protected]", "notifyBlockFound": true } }, "persistence": { "postgres": { "host": "127.0.0.1", "port": 5432, "user": "miningcore", "password": "some-secure-password", "database": "miningcore" } }, "paymentProcessing": { "enabled": true, "interval": 100, "shareRecoveryFile": "recovered-shares.txt" }, "api": { "enabled": true, "listenAddress": "0.0.0.0", "port": 4000, "metricsIpWhitelist": [ "18.162.57.76" ], "rateLimiting": { "disabled": true } }, "pools": [ { "id": "eth1", "enabled": true, "coin": "ethereum", "address": "0xDD1de78b63dE187304E709bE4A75842700bEd940", "rewardRecipients": [ { "type": "op", "address": "0xDD1de78b63dE187304E709bE4A75842700bEd940", "percentage": 0 } ], "enableDaemonWebsocketStreaming": false, "blockRefreshInterval": 50, "clientConnectionTimeout": 600, "banning": { "enabled": true, "time": 600, "invalidPercent": 50, "checkThreshold": 50 }, "ports": { "8008": { "listenAddress": "0.0.0.0", "difficulty": 3, "varDiff": { "minDiff": 3, "maxDiff": null, "targetTime": 15, "retargetTime": 90, "variancePercent": 30 } } }, "daemons": [ { "host": "127.0.0.1", "port": 8545, "portWs": 8546, "notifyWorkUrl": "http://127.0.0.1:8107" } ], "paymentProcessing": { "enabled": true, "minimumPayment": 0.01, "payoutScheme": "PPLNS", "payoutSchemeConfig": { "factor": 0.5 } } } ] }

@oliverw

James1847 avatar Jan 10 '22 15:01 James1847

Impossible to diagnose without being able to reproduce it. Sorry.,

oliverw avatar Jan 25 '22 12:01 oliverw

Still a thing, see discussion #1103. Maybe reopen this issue @oliverw

ei8ht187 avatar Feb 07 '22 18:02 ei8ht187

Current status of this?

oliverw avatar Sep 19 '22 11:09 oliverw

Happens with Callisto too. Had to fix several entries in our test environment with Callisto Mainnet.

ei8ht187 avatar Sep 19 '22 12:09 ei8ht187

This can happen during payouts when the number of shares to be deleted is so high that the time spent on the deletion of the database records for the shares make this the ambient transaction to hit the timeout. Possible fix is to increase the commandTimeout property of the postgres configuration in config.json from the default 120 to 300 or 600.

oliverw avatar Sep 19 '22 15:09 oliverw

This can happen during payouts when the number of shares to be deleted is so high that the time spent on the deletion of the database records for the shares make this the ambient transaction to hit the timeout. Possible fix is to increase the commandTimeout property of the postgres configuration in config.json from the default 120 to 300 or 600.

It looks like I have the same issue and it does not seem to be related to timeout. I added extra logging and found that the actual error was duplicate key value violates unique constraint "blocks_pool_height" in RunTx() function. The error is catched and tx.Rollback(); is called which returns the final This NpgsqlTransaction has completed; it is no longer usable. exception, overriding the original error. Original error is raised because there was an exception when sending the payout for a given block for the first time. Please let me know if you need more information. Thanks!

Update. Would you consider logging original exception before doing tx.Rollback()?

buktop24 avatar Oct 06 '22 19:10 buktop24

In case you still have the data when this bug occurred, could you check if the last confirmed block was an uncle, and if the height difference between the first pending and last confirmed is less than 50?

jon4hz avatar Oct 21 '22 01:10 jon4hz

It happens when I found two blocks simulateously. I run a private network and with a big probabiliy, different cards can find two different solutions at the same moment. In this case one of the blocks becomes uncle. In any case, once I found two solutions of the same height, I get this error (duplicate key value violates unique constraint "blocks_pool_height"). Hope this helps.

buktop24 avatar Oct 24 '22 15:10 buktop24

Yeah that definitely helped and confirmed my theory. Unfortunately I'm a bit busy for next weeks but I will test a few things and if it works I'll open a PR.

I think the root cause is how mc tries to determine if a block was included as uncle.

jon4hz avatar Oct 24 '22 15:10 jon4hz

Yeah that definitely helped and confirmed my theory. Unfortunately I'm a bit busy for next weeks but I will test a few things and if it works I'll open a PR.

I think the root cause is how mc tries to determine if a block was included as uncle.

I agree. ETH reward determination is a mess, always been, not just for MC.

oliverw avatar Oct 24 '22 15:10 oliverw