The wallet can contain transactions that are not accepted into the node's mempool (eg due to containing a too large OP_RETURN output, due to too low a feerate, or due to too many unconfirmed ancestors). In the event you end up in this situation, it can appear as if funds have gone missing from your wallet due to the non-mempool balance not being reported. Correct this by reporting the non-mempool balance.
See bitcoin/bitcoin#33671 for further context.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process. A summary of reviews will appear here.
<!--174a7506f384e20aa4161008e828411d-->
No conflicts as of last run.
<!--5faf32d7da4f0f540f40219e4f7537a3-->
To test, start with -datacarriersize=10, and run
send '{"data": "4368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73"}' null "unset" 1
from the console. "Non-mempool: <change amount>" should appear in the Balances pane on the Overview window with the change from the transaction. Restarting with -datacarriersize=100000 should allow the tx to enter the mempool, and move the amount into the Available balance. (Presumably, do this on -regtest after generating 100 blocks; or perhaps signet after grabbing some funds from a faucet)
Screenshot:
<img width="318" height="218" alt="non-mempool-gui" src="https://github.com/user-attachments/assets/885411f4-d01a-4574-a341-98b962c5c2ec" />
The negative sign for the non-memool stuff isn't really very clear, perhaps.
Rebased after merge of parent PR, should be ready to review. Happy to close if some someone wants to take over.
Maybe I'm not understanding the issue, but does this matter? If that is a transaction we created we will not broadcast it. If that is a transaction we are receiving we will not be able to spend the outputs until it is confirmed as the child will be rejected by our mempool.
So I am not really getting the issue, we just need to wait for it to be confirmed.
IIUC this only makes sense for private-broadcast.
Worst case, I guess: if you make a transaction that doesn't hit the mempool, it won't be visible in your balance, which may lead you to try to make the same transaction again. That might happen if the first transaction was spending some unconfirmed outputs from large transactions, so your new transaction would have exceeded the cluster size limits. Once those large transactions confirm, your nonmempool transaction will be broadcast and able to be confirmed.