Check update_data:<br>
https://gogs.veloe.link/TooManySugar/GoEthemineTelegramBot/src/69f25124457b342a9a9ef0696bee460bbbbdfff7/update_data.go#L258<br>
Most likely compares time to self time. Due to logic diff of cs entity and gorm
Fixed in 4f294e09f2
Problem was in a time differences at given by pool api stats for miners/workers and payouts. It is possible to get payout`s time higher then updated time of miners/workers and then this issue occurs: so at update with payout would be written right up to date entry. Which will be considered an error in the next update.
Fix was to do actual check is it's zeroed or not if it's time less then last payout's time.
Fixed in 4f294e09f2<br>
Problem was in a time differences at given by pool api stats for miners/workers and payouts. It is possible to get payout`s time higher then updated time of miners/workers and then this issue occurs: so at update with payout would be written right up to date entry. Which will be considered an error in the next update.<br>
Fix was to do *actual* check is it's zeroed or not if it's time less then last payout's time.
Check update_data:
https://gogs.veloe.link/TooManySugar/GoEthemineTelegramBot/src/69f25124457b342a9a9ef0696bee460bbbbdfff7/update_data.go#L258
Most likely compares time to self time. Due to logic diff of cs entity and gorm
Fixed in
4f294e09f2
Problem was in a time differences at given by pool api stats for miners/workers and payouts. It is possible to get payout`s time higher then updated time of miners/workers and then this issue occurs: so at update with payout would be written right up to date entry. Which will be considered an error in the next update.
Fix was to do actual check is it's zeroed or not if it's time less then last payout's time.