Good answer

Tor is very naughty when it comes to long living connections. There is no countermeasures for failed hops in the path, and this can be caused by congestion due to the random selection of rendezvous points, which also provide you with 6 potential candidates. At one time I used to try and use SSH over it but the random timeouts (circa 2005) just made it unbearable.

I don't know what any LN node's configuration regarding this is but I don't think that any of them communicate to Tor using the RPC, just use its SOCKS5 (or 4a) proxy and at best manage the creation of hidden services. There is no "make new circuit" interface in them, as far as I know, and given enough time, 5, 10, 30 minutes, tor just decides "oh, snap, your connection is b0rked", and then it finally creates a new circuit to use for the connection.

If there was some way to trigger a new circuit for a given endpoint, either within btcd/lnd/neutrino or something more direct inside the Tor API, after a timeout starts, that isn't an absurdly long amount of time, maybe it would be better, but the problem tends to be simply that an anonymising network has few ways in order to mitigate congestion.

I was just thinking about it today, the problem of rate limiting. In my work on Indranet I will be applying a strategy where exit messages (like hidden services but endpoint not behind a rendezvous) include a little hint that gives a number that indicates the level of traffic the node is handling so it can select a different path when an exit node gets congested.

In addition to this, nodes will propagate this value across the p2p network, in their state advertisments. In response to these data points clients will be able to recognise a sustained rise in congestion and avoid nodes temporarily in such a state.

One of the reasons why Indra will be better than Tor or I2P is because of this - by using exclusively source routing, it is also hard to attack the network consensus (Tor has been under sustained attack at the centralised network consensus servers for most of the last year). Every single request your servers send out over it will travel over different paths every single time, the law of averages says that more than half the time you won't hit a speedbump anyway, and if you do, the node will detect a failed delivery and start a diagnostic to identify the failing node and avoid it for a while until its network state via ping or p2p network updates appears to be back up.

Honestly, I totally recognise and affirm the desire to anonymise but for a few million sats it's really not worth the trouble. Unless a SWAT team is gonna break down your door because your home connection was detected as running a cryptocurrency type server off it I wouldn't bother. For several bitcoins worth of channels, I'd want to have some pretty solid security, and probably works out better to just use a little collection of different VPNs instead.

Tor is a terrible network transport for latency and poor congestion control. It is a very poor fit with Lightning.

Any idea what I should be looking for? I've scanned the log line by line but nothing jumps out at me.

It wasn't a large channel. There were about 1 million sats on both sides. But wouldn't those funds (minus tx fees) get swept back to my on-chain wallet after the time lock?