I think this works, but like laolu said we already do the mapping over reject-reason. If we believe this field is less likely to be changed, what we can do instead is to always do a testmempoolaccept check in SendRawTransaction here since we can assume once it's the bitcoind backend this RPC must be supported.

I was confused about this too... So I did some digging and we do match on reject-reason. BUT we have a special case where we still publish the transaction, even when testmempoolaccept returns false: https://github.com/lightningnetwork/lnd/blob/cc9e2b783ec983fbe3995d47d31898aa122b11c8/lnwallet/btcwallet/btcwallet.go#L1302

And in that case we then get the new error message, which we need to map as well.
So I think we still need this, cc @yyforyongyu @Roasbeef.

I was confused about this too... So I did some digging and we do match on reject-reason. BUT we have a special case where we still publish the transaction, even when testmempoolaccept returns false: https://github.com/lightningnetwork/lnd/blob/cc9e2b783ec983fbe3995d47d31898aa122b11c8/lnwallet/btcwallet/btcwallet.go#L1302

Yeah we do call publish tx even if there's an error in lnd, to put the tx label in the db...we may need to fix it there, meanwhile this should be good to go.

Ahh yeh, we call again just to insert it as a label...