Summary
The documentation of v_tx_outputs describes a diversifier_index_be column (db.rs#L1535-L1537):
diversifier_index_be: The big-endian representation of the diversifier index (or, for transparent addresses, the BIP 44 change-level index of the derivation path) of the receiving address. This will be NULL for outgoing transaction outputs.
but the view never emits it. Both arms of the unioned CTE select the column (db.rs#L1570 and the sent arm's NULL), and the outer merge projection (db.rs#L1608-L1630) then drops it — its column list goes directly from to_address to value. SELECT diversifier_index_be FROM v_tx_outputs fails with "no such column", and the CTE selection is dead code.
Provenance
The column entered the CTE with the v_tx_outputs_return_addrs migration (e02889e), the implementation of #1951 — whose title asks to expose the address and diversifier index at which each output is received. The address half shipped (and was recently corrected in #2845 / #2857); the diversifier-index half made it into the CTE and the column documentation, but never into the view's output, and has been carried forward verbatim ever since (first affected release: zcash_client_sqlite 0.18.1).
Because every query naming the column has always failed immediately, no consumer can currently depend on it; projecting it now is purely additive.
Suggested fix
Recreate the view with the column projected through the outer merge, e.g. MAX(diversifier_index_be) AS diversifier_index_be following to_address. The merge semantics work out: for an output the wallet both sent and received, the received arm's non-NULL index wins over the sent arm's NULL, and rows for outputs sent to external recipients remain NULL. The documented NULL condition should be restated accordingly ("not received at one of the wallet's diversified addresses" rather than "outgoing"), since a wallet-internal transparent send now carries the receiving address's index.
Filed with the assistance of Claude Code (Claude Fable 5).
Summary
The documentation of
v_tx_outputsdescribes adiversifier_index_becolumn (db.rs#L1535-L1537):but the view never emits it. Both arms of the
unionedCTE select the column (db.rs#L1570 and the sent arm'sNULL), and the outer merge projection (db.rs#L1608-L1630) then drops it — its column list goes directly fromto_addresstovalue.SELECT diversifier_index_be FROM v_tx_outputsfails with "no such column", and the CTE selection is dead code.Provenance
The column entered the CTE with the
v_tx_outputs_return_addrsmigration (e02889e), the implementation of #1951 — whose title asks to expose the address and diversifier index at which each output is received. The address half shipped (and was recently corrected in #2845 / #2857); the diversifier-index half made it into the CTE and the column documentation, but never into the view's output, and has been carried forward verbatim ever since (first affected release:zcash_client_sqlite 0.18.1).Because every query naming the column has always failed immediately, no consumer can currently depend on it; projecting it now is purely additive.
Suggested fix
Recreate the view with the column projected through the outer merge, e.g.
MAX(diversifier_index_be) AS diversifier_index_befollowingto_address. The merge semantics work out: for an output the wallet both sent and received, the received arm's non-NULLindex wins over the sent arm'sNULL, and rows for outputs sent to external recipients remainNULL. The documentedNULLcondition should be restated accordingly ("not received at one of the wallet's diversified addresses" rather than "outgoing"), since a wallet-internal transparent send now carries the receiving address's index.Filed with the assistance of Claude Code (Claude Fable 5).