Rarely, a node accepts a transaction but it isn't actually mined. This might indicate a network failure somewhere. There should be a secondary direct sequencer dispatcher that does first IN_NETWORK-1 nonce dispatch for all transaction from that origin account.
E.g. if account 1 has a IN_NETWORK nonce of 256, we force dispatch all transaction >= 255 again without checking the return HTTP status code.
To filter such transactions:
SELECT otx.id, otx.tracking_id, otx.otx_type, keystore.public_key, otx.raw_tx, otx.tx_hash, otx.nonce, otx.replaced, otx.created_at, otx.updated_at, dispatch.status FROM keystore
INNER JOIN otx ON keystore.id = otx.signer_account
INNER JOIN dispatch ON otx.id = dispatch.otx_id
WHERE dispatch.status NOT IN ('SUCCESS', 'REVERTED', 'PENDING', 'EXTERNAL_DISPATCH') AND otx.otx_type NOT IN ('GENERIC_SIGN', 'OTHER_MANUAL')
ORDER BY otx.id ASC LIMIT 100;As of now, this is a minor issue. This should be part of a health check that runs every 5 min or so.
Rarely, a node accepts a transaction but it isn't actually mined. This might indicate a network failure somewhere. There should be a secondary direct sequencer dispatcher that does first IN_NETWORK-1 nonce dispatch for all transaction from that origin account.
E.g. if account 1 has a IN_NETWORK nonce of 256, we force dispatch all transaction >= 255 again without checking the return HTTP status code.
To filter such transactions:
As of now, this is a minor issue. This should be part of a health check that runs every 5 min or so.