mpool: messages stuck if have incorrect/stalled fee configuration

[jsign]

Problem:
Pending messages from a wallet address may get "stuck" if one or more of those messages have an incorrect/outdated/stalled gas-feecap.

This is something that has happened to miners, but in my case also as a client. The problem is unrelated to being a miner, client, or what kind of message you're sending.

The operator (client/miner) should do something about this or most probably, the messages will be stuck forever. (or until the base-fee have some reasonable drop to make some equations happy)

Even if new messages are sent with fee values, they will be stuck until the previous problematic message gets unstuck (not a problem, just a consequence of processing msgs in nonce order).

Depending on the user intentions, there're two solutions:

1. Replace the problematic messages with correct gas-feecap and gas-premium values. This makes sense if the stuck messages are still meaningful to include on-chain.
2. Replace the problematic messages with zero-send transactions to "wipe" them out and get unstuck from this situation while paying as little FIL as possible.

Situation 1:
For situation 1. above, there is lotus mpool replace --auto which should update both gas-premium and gas-feecap. It looks like it only corrects gas-premium. Looking at the code it seems that it has gas-feecap updating logic, but there might be something working wrong. I used this to unstuck a message, and it only changed the gas-premium.

Situation 2:
In this case, we'd want to unblock the problematic message but not execute the original message intention. So, in this case, we want to replace the message with a zero-fil send to spend as little FIL possible to get unstuck.

There's a very detailed explanation of the manual solution here. I haven't tried that out yet, but I'm pretty sure that works.

It would be useful to make this available in some other lotus mpool replace flag, since doing this manually is quite hard.

One particular thing to mention is that the client should know what's doing since the created txns might be part of a bigger scope process such as deal-making or some other process that requires multiple transactions. If they're replaced with zero-fil send messages, that might leave some process in an undesired state.

[dineshshenoy]

cc: @magik6k @Kubuxu

[dineshshenoy]

Needs a bit more scoping

[jennijuju]

Related #5333

[arajasek]

@schomatis Any update on this?

[schomatis]

@arajasek Not really, didn't have enough cycles at the time to page in all the required context. If this is still a valuable target for the stewards team I can allocate some time (likely end of week or start of the next one), otherwise I should unassign myself.

[arajasek]

Ack, thanks @schomatis! Gonna unassign you and pull in the Ingite folks, because it does fit within @Kubuxu's work quite well.

[arajasek]

Sounds like there's maybe multiple things being captured here.

For situation 1. above, there is lotus mpool replace --auto which should update both gas-premium and gas-feecap. It looks like it only corrects gas-premium. Looking at the code it seems that it has gas-feecap updating logic, but there might be something working wrong. I used this to unstuck a message, and it only changed the gas-premium.

That kinda sounds like we just have a bug. Need to review that logic.

The rest of it is partially or fully addressed by @Kubuxu's ongoing message-sending work.

[hsn999]

we want to replace the message with a zero-fil send to spend as little FIL possible to get unstuck ?

Cloud you tell me how to do it?

I want to login salck,but it display -- doesn’t have an account on this workspace.