fix(sequencer-relayer): poll Celestia App for transaction status

[ethanoroshiba]

Summary

Changes polling method for confirming Celestia commitment from GetTx gRPC to TxStatus.

Background

Previously, GetTx was polled indefinitely. On the client end of this RPC, we'd have no indication of what's happening on Celestia, so we had no way to know if a transaction was, for instance, evicted from the mempool, which would cause a halt of data submission. The TxStatus endpoint solves this problem by providing a more detailed status of the transaction.

Changes

• Poll TxStatus instead of GetTx. The client will behave in the following ways:
  • Status is PENDING: continue polling
  • Status is UNKNOWN: continue polling until MAX_WAIT_TIME_UNKNOWN is reached (currently 6s)
  • Status is COMMITTED: return block height
  • Status is EVICTED: return an error

Testing

• Adjusted mounts as necessary.
• Added blackbox tests for each possible status response.

Changelogs

Changelog updated.

Metrics

• Added unknown status transaction count.
• Added evicted transaction count.

Related Issues

closes #1936

[ethanoroshiba]

This is an abhorrently long time for a test to take, but we need to test that the relayer correctly exits if the allotted time passes without the status changing from "UNKNOWN". We cannot advance time manually due to the multithreaded context, so I'm not sure of a way around this :/

[Fraser999]

We could perhaps change the actual timeout based on the test feature:

#[cfg(test)]
const MAX_WAIT_FOR_UNKNOWN: Duration = Duration::from_secs(2);
#[cfg(not(test))]
const MAX_WAIT_FOR_UNKNOWN: Duration = Duration::from_secs(10);

Alternatively, 10 seconds might be too long anyway given that Celestia block time is now 6 seconds?

[ethanoroshiba]

In 4f304bb I lowered the time to 6s and the minimum logging time to 3. I'm not sure how I feel about building the testing functionality into the source code, but I'll defer to you here on what you think is best, since I think I lack the context of what is best practice. I feel like generally, though, it's best to keep testing logic (especially for blackbox tests) separate

[Fraser999]

Mostly looking good. Just a few comments.

[Fraser999]

Just wondering about the rationale for changing the retry backoff and removing the START_LOGGING_DELAY? Seems like that behaviour is still desirable?

[ethanoroshiba]

I suppose I thought because this functionality was moved to the debug level, it could be helpful to have the full picture of each response the relayer has received. I don't have a strong opinion on this, though, so I'd be happy to add that back if you think it's better

[Fraser999]

We could perhaps change the actual timeout based on the test feature:

#[cfg(test)]
const MAX_WAIT_FOR_UNKNOWN: Duration = Duration::from_secs(2);
#[cfg(not(test))]
const MAX_WAIT_FOR_UNKNOWN: Duration = Duration::from_secs(10);

Alternatively, 10 seconds might be too long anyway given that Celestia block time is now 6 seconds?