JDSMissingTransactions error after a ProvideMissingTransaction sent by JDC #860
Comments
GitGab19
added
bug
|
in the jd_client the handler for the fn handle_provide_missing_transactions(
&mut self,
message: ProvideMissingTransactions,
) -> Result<SendTo, Error> {
let tx_list = self
.last_declare_mining_job_sent
.clone()
.unwrap()
.tx_list
.into_inner();
let unknown_tx_position_list: Vec<u16> = message.unknown_tx_position_list.into_inner();
let missing_transactions: Vec<binary_sv2::B016M> = unknown_tx_position_list
.iter()
.filter_map(|&pos| tx_list.get(pos as usize).cloned())
.collect();
let request_id = message.request_id;
let message_provide_missing_transactions = ProvideMissingTransactionsSuccess {
request_id,
transaction_list: binary_sv2::Seq064K::new(missing_transactions).unwrap(),
};
let message_enum =
JobDeclaration::ProvideMissingTransactionsSuccess(message_provide_missing_transactions);
Ok(SendTo::Respond(message_enum))
}The issue here is Also if this should be fixed, this is not the cause at least sometimes is not. Running the client + server for several hours with the below patch: if missing_transactions.len() != unknown_tx_position_list.len() {
std::process::abort();
};We still have the |
|
Looking at the code my best guess is that something like the below happens:
In that case when the jds call We should leverage the MG to test things like that. MG tests are thought to be highly composable. So we could have a file with several valid bitcoin txs serialized, that can be used in the tests. For example here we should add a test for the JDS, the test will act like a JDC and it will look somthing like that:
|
|
In order to fix it, I think that we could add a ring buffer with capacity 3 (should be enough) where we put the request ids of the
|
|
even simpler would be correct also ingore every |
I'm running the JDC with this patch, I will let you know. |
I'm also pretty confident this is exactly what is happening. It seems to me that this can go wrong after new blocks found (not completely sure if it's related to it btw) |
If the problem is the one you described, I would go with this solution |
|
To give more context and confirm your thesis, here's a screenshot of JDC logs: The issue happens sometimes after a new block is found, if time between two blocks is very little. |
Here's JDS logs:
And JDC logs:
The text was updated successfully, but these errors were encountered: