#187 is a duplicate of #157
in both issues, we describe a bug that should have been caught via jd_aggregated_tproxy_integration Integration Test (at least on its current form)
more specifically, this codeblock is giving a false positive:
// assert that only one OpenExtendedMiningChannel message is present in the queue
{
tproxy_jdc_sniffer
.wait_for_message_type_and_clean_queue(
MessageDirection::ToUpstream,
MESSAGE_TYPE_OPEN_EXTENDED_MINING_CHANNEL,
)
.await;
tokio::time::sleep(std::time::Duration::from_secs(1)).await;
tproxy_jdc_sniffer
.assert_message_not_present(
MessageDirection::ToUpstream,
MESSAGE_TYPE_OPEN_EXTENDED_MINING_CHANNEL,
)
.await;
}the message does happen twice, yet the test still passes
tbh I don't have a clear picture of how we can solve this, but logging this issue so we can do something about it
#187 is a duplicate of #157
in both issues, we describe a bug that should have been caught via
jd_aggregated_tproxy_integrationIntegration Test (at least on its current form)more specifically, this codeblock is giving a false positive:
the message does happen twice, yet the test still passes
tbh I don't have a clear picture of how we can solve this, but logging this issue so we can do something about it