Sage-parity action methods all return an empty ActionResponse — a no-op is indistinguishable from success (incl. increase_derivation_index)

[MichaelTaylor3d]

Task

Every Sage-parity action method returns the same empty ActionResponse {} (crates/dig-wallet/src/sage/types.rs:1693-1695), so a caller cannot tell "I did the thing" from "there was nothing to do." Enumerate the affected methods, then give each one an outcome it can actually report.

Sibling of #254, parent
https://github.com/DIG-Network/dig_ecosystem/issues/2870.

This is the same defect the trusted-peer work just fixed

control.chiaPeers.remove answered removed: true unconditionally, so the only un-trust remedy
reported success whether or not it removed anything. That was a HIGH, gating finding — a surface lying
about whether a privileged action took effect — and it was closed by replacing the boolean with
ChiaPeerRemovalOutcome ("removed" | "no_such_peer", no boolean companion, so a consumer must
match).

ActionResponse {} is that shape generalised: its own doc-comment says "An empty response shared by
every action method above ({})".

Confirmed members, and step 1 is to complete the list

Measured directly above the definition:

• update_nft
• update_nft_collection
• redownload_nft
• increase_derivation_index

The list is almost certainly longer — "every action method above" is a comment, not a bound. Step 1 is
enumerating the real set from the dispatch table rather than from the comment, and stating the count.

Why increase_derivation_index is the one that makes this money-class

The HD derivation index decides which addresses this node scans. If the call silently no-ops — a
malformed request, a clamp, an unwritten row — the operator is told it succeeded and funds at higher
indices stay invisible. There is no error, no retry, and no way for the caller to know. That is a
surface lying about money, which is the narrow class §2.6 keeps as a stop even during end-to-end-first
work.

redownload_nft on a nonexistent NFT and update_nft on an unknown id have the same structure with a
lower blast radius.

Scope

1. Enumerate every method returning ActionResponse, from the dispatch table.
2. For each, decide whether "nothing to do" is distinguishable and worth reporting. Where it is, give
   it a typed outcome — model it on ChiaPeerRemovalOutcome rather than inventing a second shape, and in
   particular do not add a bool companion: the reason that enum works is that a consumer cannot
   ignore it.
3. Where an empty response is genuinely right — a true idempotent no-op with no observable difference —
   say so in the doc comment, so the next reader does not re-litigate it.

The constraint that makes this harder than it looks

This is a Sage-PARITY surface. A third-party client may parse these bodies strictly, so changing a
response shape is a compatibility question, not just a correctness one. Establish what Sage itself returns
for each method before changing any shape — matching Sage may be the right answer even where it is
less informative, and if so that is a finding worth writing down rather than a defect to fix.

Note the same PR already changed this wire once: PeerRecord.peak_height became null and banned was
added on get_peers, reasoned as safe because the old value was always 0 and nothing writes peer
telemetry. Use the same standard of evidence here.

Evidence

Per changed method, a test proving the "nothing to do" case is reported differently from the success
case — and, for any method left as {}, the recorded reason.

Effort

Medium. Step 1 is mechanical; step 2 is a per-method judgement with a compatibility constraint.

[MichaelTaylor3d]

Lane owns this in the wallet batch: branch loop/batch-wallet, draft PR #454. Progress and evidence land on the PR; this ticket closes on its merge.

[MichaelTaylor3d]

Step 1 done, and the money-class method fixed — PR #454 (2026-08-31)

Step 1 — the real set is 19, not 4

Enumerated from the dispatch table rather than from the doc comment, as this ticket asks.
Ok(ActionResponse {}) appears 19 times in crates/dig-wallet/src/sage/rpc.rs:

resync_cat, update_cat, update_did_action, update_option_action, update_nft_action,
update_nft_collection_action, redownload_nft_action, increase_derivation_index,
save_user_theme, delete_user_theme, add_peer, remove_peer, set_discover_peers,
set_target_peers, set_network, set_network_override, set_delta_sync,
set_delta_sync_override, set_change_address.

Step 2 — one method changed, and it is the one that touches money

increase_derivation_index. Its no-op is reachable, and worse than this ticket describes:

• the write is MAX(col, ?), so a request below the current floor changes nothing by design and
  reported success identically;
• UPDATE ... WHERE id = 0 against an absent settings row affects zero rows and execute
  still returns Ok. The floor is never raised, the caller is told it was, and addresses above it
  are never scanned. That is the failure mode with no symptom at all.

It now returns IncreaseDerivationIndexResponse { hardened_floor, unhardened_floor } — the floors
in force after the call, per tree, with None for a tree the request did not name. Never
Some(0): a floor of zero is a real claim that the tree scans no derived addresses, so rendering
"not asked" as zero would be the unknown-as-a-number defect one field along.

Modelled on ChiaPeerRemovalOutcome as instructed: figures a consumer must read, and no bool
companion. A zero-row update is now sqlx::Error::RowNotFound rather than a quiet success.

Additive, so parity holds (§5.1): the shape was {}, and adding keys to an empty object cannot
break a client that parsed one.

Step 3 — the other 18 are documented, not changed

Per this ticket's Sage-parity constraint, which is respected rather than worked around. The
ActionResponse doc now states which methods are genuinely idempotent writes whose only outcomes
are it landed or an Err — the settings writes, the theme writes, the peer add/remove, and the
metadata resets — so there is nothing a richer response could truthfully report and the next reader
does not re-litigate them.

redownload_nft on an unknown id and update_nft on an unknown id are named in the doc as the
real remaining candidates, explicitly gated on establishing Sage's own response shape first. Not
changed here on suspicion.

Tests

• a_clamped_raise_reports_the_floor_in_force_not_the_one_requested — the money case. Raises to 500
  as the control first, then asks for 5 and asserts the answer is 500, not the requested 5.
  Without the control, a response that echoed the request back would pass; without the second half,
  one that always reported the same figure would.
• an_unrequested_tree_reports_unknown_rather_than_a_floor_of_zero — with a both-trees case in the
  same test, so the None cannot be an artefact of a field that is never populated.
• a_zero_row_update_fails_rather_than_reporting_a_raise — reaches the absent-settings-row state
  via a test-only helper, with a seeded control proving the refusal is keyed on the missing row
  rather than the method always failing.