An Electron Cash SLP workaround I needed today

Going to describe some steps taken to work around a little Electron Cash SLP (v3.6.1) wallet issue I encountered today, in case it helps others.

I tried various things to resolve before coming across this way which worked for me.

I won't go into too much detail (screenshots etc) for privacy reasons.

The Problem

It started when I wanted to transfer some tokens of a particular type (I'll call them ACME tokens) from my Electron Cash (EC) wallet to another wallet.

When trying to send, EC refused, giving me an error message complaining that

Transaction contains an SLP input that is unknown to this wallet (missing from slp_txo)

Huh?

I've never before had any trouble with this particular wallet file, nor really with EC SLP edition. This was curious!

Using the SEND dialog's transaction PREVIEW function, I looked at what the wallet was including while composing this deficient transaction.

To my surprise, I found that it was including some inputs which were allocated to another token, unrelated to the one I wanted to send.

EC-lia, you're breaking my heart

You're shaking my confidence daily

Oh EC-lia I'm down on my knees

I'm begging you please to come home

The transaction did contain the inputs that held the token I did want to send, but these extra tokens (let's designate them: NAUGHTY tokens) were somehow not supposed to be there. It seems they were added to supply the fee, which was just over 800 satoshis, and there were three extraneous "other-token" inputs, which would satisfy the sending fee and leave the resulting output with enough satoshis.
`Curiouser and curiouser!' I cried.

The wallet had clearly made a mistake selecting these inputs which held another tokens which I definitely did not want to send!
I don't think it should ever do that on a simple Send, but bugs happen. This is not an article describing the wallet fix - just a work around I found which helped me get past this problem.

Possible contributing factor

I don't know if it matters, but I had, long ago, intentionally frozen one or two addresses holding the NAUGHTY tokens because I had received some of them which I didn't want to mix with other transactions.
Thus I had "quarantined" a couple of those tokens a while back, using the "Freeze" function.

Searching for a workaround

I'll briefly describe some things that didn't help. If you want to, you can skip to the next section to see what worked.

1. Trying to send smaller amounts of the ACME token, in order for the EC wallet to possibly select a different set of inputs (the ACME token amounts were held in several different UTXOs). Selecting an amount to send matching the smallest ACME input amount did not result in that output being picked. The wallet actually picked a bigger output and wanted to break it up. It still added those NAUGHTY tokens which didn't belong, so that wasn't going to cut it.

2. Rebuilding the wallet history. I stopped my wallet, then made a backup of the wallet file. That much is common sense and the history rebuild dialog will also helpfully advise you to do it - always heed those warnings.
   The wallet rebuild was fast and looked good, but it changed nothing. I wasn't really expecting it, but I thought there was a slim chance it might help, based on the error message which indicated an output which was somehow missing from the internal SLP UTXO set.

3. Switching on graph server use in the Network settings. I'd not played around with this before, but it didn't make any difference except in speed. I did not really expect it to make a difference to the problem I was facing either.

4. Adding a small amount of BCH to my SLP wallet to ensure that there was at least one input containing sufficient funds to cover the transaction fee, and that it might inspire the wallet not to pick those unwanted token inputs. No luck.

What worked

What helped was to freeze all the NAUGHTY tokens in my wallet, then do the ACME transaction.

This successfully excluded them all from my transaction, and fortunately no other tokens slipped in there, resulting in a clean transaction that could be sent.

The additional BCH sats I had deposited turned out not be used in the transaction. I had been pretty sure that the wallet held enough free funds to do the SLP send I wanted anyway.

I'll experiment with unfreezing those NAUGHTY tokens that weren't frozen before, and see if I get further problems sending other tokens with the wallet.

I have no idea what caused this issue to surface. I've been using the wallet regularly, without any problems.

Maybe this report can help someone else who might run into a similar issue.