added a comment - - edited
I want to ask a question about your questions. And I want to use the language that is present in the boincwork_host_merge function, where variables $old_host is the 'host being merged' and $new_host is the 'target host'.
So this translates as (please correct me if I am wrong):
- Given our host merge feature, is there a possibility that the host.rpc_seqno value of the $old_host is set to the host_id of the $new_host, despite the fact that the $new_host's host.rpc_seqno points back to $old_host?
- A: Yes, $old_host has its rpc_seqno set as part of the merge. It is set to rpc_seqno of ‘$new_host’, without any stricter checks. Including pointing back to the host being merged ($old_host).
- Alternatively, does our host merge feature allow
to set [the setting of] the host.rpc_seqno of $old_host to a host ID of a $new_host that's also a "zombie" (userid==0)?
- A: Yes. $old_host has its rpc_seqno set as part of the merge. It may be set to anything without any stricter checks. Including setting to a host ID where that’s hosts userid is equal to zero (userid==0).
These could be fixed around line 808. We can introduce a function to check the value of rpc_seqno before running the DB update query. We could check for the circular pointers that you describe (pointing at itself in Q1), and that it is not set to a host with userid==0 (pointing to a zombie as in Q2).