DO NOT REVIEW - Fix CI

[dannywillems]

This test was never migrated to the Z3 stack. It passed a list of zcashd-style args to start_node, which now expects a ZebraArgs dataclass, so it crashed during setup_network with "'list' object has no attribute 'miner_address'". Because it inherits required: true from the Ubuntu 22.04 platform in CI, the failure blocked required runs.

Move it out of FLAKY_SCRIPTS into a new, documented DISABLED_SCRIPTS list so it is excluded from the default run until it is migrated. A faithful migration is non-trivial: the test exercises the Blossom, Heartwood, Canopy and NU5 activation boundaries, but zebra regtest hardcodes everything up to Canopy to height 1, and it relies on -blockmaxsize to overflow the mempool, which the zebra regtest config does not expose.

Also convert setup_network to pass a ZebraArgs dataclass built from the original activation heights, dropping the zcashd-only flags that have no ZebraArgs equivalent, so the argument-passing crash is fixed regardless.

[oxarbitrage]

Thanks for digging into this @dannywillems — the process-lifecycle hardening here is genuinely valuable, and the per-test analysis of why each test can't run is excellent. I validated things end-to-end; below is the full picture and a suggested way to split the work, since this PR overlaps a couple of others. Treat the breakdown as a proposal — happy to adjust if you see it differently.

The CI red looks like an upstream blocker, not anything in this diff. The required shards fail in create_cache.py → rebuild_cache() with:

Failed to synchronize zallet: InvalidData { message: "Missing Orchard tree state" }

That's zcash/wallet#454 (fixed by zcash/wallet#455, not yet merged). CI builds stock zallet, so the cache rebuild crashes before any test in the list runs — so disabling tests can't get the rollup green on its own. Nothing on the integration-tests side goes green until #455 lands.

This PR is effectively three changes, and two overlap existing PRs, so there's a clean opportunity to split it:

1. Process-lifecycle hardening (PROCESS_STARTUP_TIMEOUT, bounded waits, stop_all_processes) overlaps test framework: bound process-shutdown waits to avoid multi-hour hangs #102 — and it's the most valuable piece: it turns the #454 crash from a 6-hour hang into a fast failure (ci: make SERIAL/FLAKY RPC shards non-required #101's run hit the 6h ceiling vs. ~5s with the bound). Your startup-wait timeout was the bit test framework: bound process-shutdown waits to avoid multi-hour hangs #102 was missing, so I've grafted that idea into test framework: bound process-shutdown waits to avoid multi-hour hangs #102 and credited you as co-author on that commit. Suggest dropping part 3 here and letting test framework: bound process-shutdown waits to avoid multi-hour hangs #102 carry it.
2. Disabling the broken tests (DISABLED_SCRIPTS) overlaps ci: make SERIAL/FLAKY RPC shards non-required #101, but they layer nicely: ci: make SERIAL/FLAKY RPC shards non-required #101 fixes the underlying matrix bug (the required flag is stamped per-platform instead of per-shard) and is the home for genuinely-flaky quarantines, while DISABLED_SCRIPTS is the right tool for the six deterministically-broken (not flaky) tests. Suggest rebasing the disable on top of ci: make SERIAL/FLAKY RPC shards non-required #101's per-shard mechanism rather than emptying SERIAL_SCRIPTS/FLAKY_SCRIPTS wholesale.
3. ZebraArgs migration of mempool_nu_activation.py — 👍 great as-is.

How it fits together: #102 (hardening) + #101 (matrix mechanism) + this PR (the DISABLED_SCRIPTS taxonomy + ZebraArgs migration), coordinated rather than competing — #102 landing first so the others fail fast instead of hanging, and everything able to go green once #455 merges.

One small thing: the "Fix CI" title undersells the work — maybe "test framework: disable unmigrated RPC tests + migrate mempool_nu_activation to ZebraArgs" once part 3 is split out.

[oxarbitrage]

Correction to my comment above — I'd reviewed an earlier push and missed your three latest commits (the NU5-activation work). They change the picture:

Retracting the "nothing goes green until zcash/wallet#455" claim. Your REGTEST_ACTIVATION_HEIGHTS = {"NU5": 1} is the better root-cause: the Missing Orchard tree state crash came from zebrad starting without NU5 while zallet.toml activates NU5 at height 1 — they disagreed, so zebra returned no Orchard treestate. Aligning them makes the cache rebuild succeed without the upstream #455 fix. Nice catch — that was a harness misconfiguration we'd been reading as a pure upstream blocker.

The remaining 0/13 is a config asymmetry the NU5 change introduced — and it's a one-line-ish fix. The cache is always built with NU5 (initialize_chain/rebuild_cache), but setup_nodes() only passes NU5 when miner_addresses is set, which only happens for num_wallets > 0. So every non-wallet test starts zebra with args = None (no NU5) and then loads the NU5-built cache → the cached chain's history root doesn't validate:

failed to commit non-finalized block from backup directory
  commit_error=InvalidBlockCommitment(InvalidChainHistoryRoot { ... }) height=Height(97)

Reproduced locally: a clean-cache httpbasics.py run fails with exactly this, while the cache itself builds fine (no Missing Orchard tree state), confirming it's the cache-vs-node config mismatch rather than anything upstream. That's why even httpbasics.py / nodehandling.py fail. Fix is to apply REGTEST_ACTIVATION_HEIGHTS to all nodes in setup_nodes(), not just when miner addresses exist — e.g.:

def setup_nodes(self):
    args = [
        ZebraArgs(
            miner_address=(self.miner_addresses[i] if self.miner_addresses else None),
            activation_heights=dict(REGTEST_ACTIVATION_HEIGHTS),
        )
        for i in range(self.num_nodes)
    ]
    return start_nodes(self.num_nodes, self.options.tmpdir, args)

(Any test overriding setup_network/setup_nodes with its own args needs the same activation heights, or its nodes won't match the shared cache.)

Minor: your bounded startup waits (PROCESS_STARTUP_TIMEOUT) and the ones I just added to #102 are the same change arrived at independently, so that part already lines up when we consolidate into #102.

The earlier layering suggestion still stands (disable on #101's per-shard mechanism; #102 as the home for the hardening), but your NU5 fix is the headline and should land regardless.

[dannywillems]

This is a WIP, no need to review for now.

[dannywillems]

I do believe it is expected to not be implemented in Zebra, as Zebra is a consensus node, and not a wallet.
Same argument for:

-allowdeprecated=z_getbalance
-allowdeprecated=z_getnewaddress

[dannywillems]

From Claude, by looking at Zebra code.

No config or flag for preferred tx version. Tx versions follow the active network upgrade / protocol rules.

[dannywillems]

From Claude, by looking at Zebra code.

Max block size is the hard-coded consensus constant MAX_BLOCK_BYTES = 2_000_000 (zebra-chain/src/block/serialize.rs:24). Not configurable.

[dannywillems]

From Claude, by looking at Zebra code.

Zebra uses tracing filters, not -debug= flags. Equivalent: set a tracing filter like zebra_mempool=debug (via the [tracing] config or the --filters arg / RUST_LOG).

[dannywillems]

From Claude, by looking at Zebra code.

Zebra has an internal mempool queue checker (zebrad/src/components/mempool/queue_checker.rs) that runs automatically, but it is not a user-facing flag/option.

[dannywillems]

Note:

auth-url-none (zebra RPC has no basic-auth)

Two tests are failing because of that.