RFC: Add end-to-end functional test coverage for sv2-tp

[enirox001]

Motivation

It may be useful to add end-to-end functional test coverage for sv2-tp.

The current C++ tests cover a lot of internal SV2 behavior, including Noise, transport, messages, connman, Template Provider behavior, mock sockets, and mock mining. However, there does not seem to be automated process-level coverage for the deployment topology users actually run:

• bitcoin-node on regtest with IPC enabled
• sv2-tp as a separate binary connected over IPC
• an SV2 client connected over TCP
• template delivery, transaction data requests, and block submission behavior across real processes

The docs already mention the regtest SRI setup as a good target for future functional test coverage.

Manual testing has also surfaced issues such as:

• sv2-tp does not exit or reconnect when bitcoin core disconnects #97
• no connection limit allows memory exhaustion under concurrent connections #98

This suggests there may be bugs that are easier to catch at the process/integration layer than inside the current C++ test harness.

Possible first step

A small CI-friendly smoke test could:

• start bitcoin-node -regtest -ipcbind=unix
• start sv2-tp -regtest -conf=0 -ipcconnect=unix
• connect a minimal SV2 test client
• complete the Noise handshake and SetupConnection
• verify initial NewTemplate / SetNewPrevHash behavior
• capture logs and fail deterministically on startup or protocol errors

Questions

• Would this kind of functional test coverage be welcome in this repository?
• Should a minimal SV2 test client be implemented in Python, or would reusing SRI components be preferable?
• Are there CI/runtime/dependency constraints that should shape the design?

[Sjors]

@enirox001 there's this: https://github.com/stratum-mining/sv2-tp/blob/master/.github/workflows/sri-integration-test.yml

[enirox001]

@enirox001 there's this: https://github.com/stratum-mining/sv2-tp/blob/master/.github/workflows/sri-integration-test.yml

Thanks, I missed that workflow.

Looking at it, it seems to provide a valuable SRI interoperability smoke test: start Bitcoin Core, start sv2-tp, start pool_sv2/mining_device, mine at least one block, and check BIP54 properties.

The gap I had in mind is more scenario-level functional/regression coverage. For example, tests that deterministically exercise reconnect/fallback behavior, repeated CoinbaseOutputConstraints, RequestTransactionData edge cases, malformed or unexpected TDP messages, stale templates, and regressions for issues like #97/#98/#99.

Would you prefer extending the existing SRI workflow for those cases, or would a lighter Python-based harness with a minimal controllable SV2 peer be more appropriate for targeted sv2-tp behavior?

[Sjors]

I would prefer expanding the existing test. Or maybe splitting it into multiple more focussed tests. I'd rather not add a more elaborate test harness.

[enirox001]

I would prefer expanding the existing test. Or maybe splitting it into multiple more focussed tests. I'd rather not add a more elaborate test harness.

Makes sense. I’ll focus on the existing SRI workflow/script path, and look at whether it can be split into smaller focused scenarios without introducing a new harness.