Skip to content
This repository has been archived by the owner on Oct 20, 2023. It is now read-only.

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

Closed
James1847 opened this issue Jan 10, 2022 · 10 comments
Labels

Comments

@James1847
Copy link

James1847 commented Jan 10, 2022

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 James1847 added the bug label Jan 10, 2022
@oliverw
Copy link
Owner

oliverw commented Jan 25, 2022

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

@oliverw oliverw closed this as completed Jan 25, 2022
@ei8ht187
Copy link

ei8ht187 commented Feb 7, 2022

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

@oliverw oliverw reopened this Mar 7, 2022
@oliverw
Copy link
Owner

oliverw commented Sep 19, 2022

Current status of this?

@ei8ht187
Copy link

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

@oliverw
Copy link
Owner

oliverw commented Sep 19, 2022

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.

@buktop24
Copy link

buktop24 commented Oct 6, 2022

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()?

@jon4hz
Copy link
Contributor

jon4hz commented Oct 21, 2022

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?

@buktop24
Copy link

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.

@jon4hz
Copy link
Contributor

jon4hz commented Oct 24, 2022

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.

@oliverw
Copy link
Owner

oliverw commented Oct 24, 2022

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants