fix: A set of qdata/qwatch related fixes#5745
Conversation
…sages, only the final one
…oring qwatch on our side Checking for `qwatch` doesn't make sense in these conditions because it's set on the node we are watching when it receives `QWATCH` message from us, it's always `false` on the watching node itself.
ogabrielides
left a comment
ogabrielides
left a comment
There was a problem hiding this comment.
Looks good in general, some nit and a question for you
There was a problem hiding this comment.
Because in this case we ask for a quorum wide data only (QUORUM_VERIFICATION_VECTOR) and not for a data about one specific MN, so proTxHash is not used in any way in this case and should not be provided. If it still was provided then maybe user doesn't quite understand what he is doing exactly or maybe he made a typo in dataMask.
There was a problem hiding this comment.
I think this would be a breaking change, no?
There was a problem hiding this comment.
why not guard this behind a category?
There was a problem hiding this comment.
const in a declaration doesn't do anything; generally this should only be present in the definition.
| void StartQuorumDataRecoveryThread(const CQuorumCPtr pQuorum, const CBlockIndex* pIndex, const uint16_t nDataMaskIn) const; | |
| void StartQuorumDataRecoveryThread(const CQuorumCPtr pQuorum, const CBlockIndex* pIndex, uint16_t nDataMaskIn) const; |
There was a problem hiding this comment.
I think this would be a breaking change, no?
|
dropped c5a66ff and 16f5e00, adjusted d0a4894 |
There was a problem hiding this comment.
utACK for squash merge; LGTM if you think c5a66ff is valuable, let's open a new PR targeted for v21 with release notes?
Approval contingent on CI
Gitlab had some unrelated issues https://gitlab.com/dashpay/dash/-/jobs/5770189961, restarted it |
knst
left a comment
knst
left a comment
There was a problem hiding this comment.
Let's refactor IsWatchQuorumsEnabled to validate fMasternodeMode (see a comment for details).
Other comments are non-actionable, just marks for conflicts resolving.
| if (msg_type == NetMsgType::QWATCH) { | ||
| if (!fMasternodeMode) { | ||
| // non-masternodes should never receive this | ||
| m_peerman->Misbehaving(pfrom.GetId(), 10); |
There was a problem hiding this comment.
just a notice: refactored in #5782 - one of these 2 PR should be changed after other is merged
| return; | ||
| } | ||
|
|
||
| if ((!fMasternodeMode && !utils::IsWatchQuorumsEnabled())) { |
There was a problem hiding this comment.
potentially conflict with #5790 - one of PR to edit; depends which one get merge first.
| } | ||
|
|
||
| { | ||
| if (fMasternodeMode || utils::IsWatchQuorumsEnabled()) { |
There was a problem hiding this comment.
I see many check "fMasternodeMode || utils::IsWatchQuorumsEnabled()" - maybe move a boolean flag fMasternodeMode inside IsWatchQuorumsEnabled such as:
bool IsWatchQuorumsEnabled()
{
static bool fIsWatchQuroumsEnabled = gArgs.GetBoolArg("-watchquorums", DEFAULT_WATCH_QUORUMS);
return fIsWatchQuroumsEnabled ||fMasternodeMode ;
}
knst
left a comment
knst
left a comment
There was a problem hiding this comment.
Let's refactor IsWatchQuorumsEnabled to validate fMasternodeMode (see a comment for details).
can be actually done after by new PR; not that important changes. utACK!
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
There was a problem hiding this comment.
re-approval to trigger conflicts check
4 participants
Issue being fixed or feature implemented
Fix/tidy up a few
qdata/qwatchrelated parts, improve performance for regular non-watching nodesbased on #5744 atmWhat was done?
pls see individual commits
How Has This Been Tested?
run tests
Breaking Changes
n/a
Checklist: