Confirmations vs commitment .how to to understand RpcResponse from a confirmation

Question

So following the answer from this thread:

How many solana transaction confirmations are enough to declare a transaction as finalized before it hits 31 and actually finalizes itself?

Solana doesn't work with the "number of confirmations" scheme that is used in Ethereum with PoW. The commitment levels are based whether a supermajority of validators has confirmed the transaction (finalized) or includes votes from gossip (inter-validator communication) and replay (confirmed). Therefore, the time to confirmed and time to finalized can vary.

and documentation from: https://docs.solana.com/developing/clients/jsonrpc-api#default

If commitment configuration is not provided, the node will default to "finalized" commitment

On the front-end, when sending transactions like so

const signature = await provider.signAndSendTransaction(transaction);
          

          const confirmation = await connection.confirmTransaction(
            {
              blockhash: latestBlockHash.blockhash,
              lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,
              signature,
            }
          );

I would get the following RpcResponse object

 const confirmationRpcResponse = {
    context: {slot: 150669448}
    value: {err: null}
    }

Is my understanding correct, that if I do not provide any commitment (in the signAndSendTransaction method) the RPC response confirmTransaction gives me information that transaction was finalized and I do not need any more "checking for confirmations", "checking for timestamps" etc. ?

Why does value key hold an err object and no actual value, like "processed" "finalized" "confirmed" - anything that would be more understandable than just slot and empty err key. How should I understand the response I got?

UPDATE 26.07.2022:

Just got the following error:

Error: TransactionExpiredBlockheightExceededError: Signature mySingature--->qYmvyL9qqsJte2TKXLyu9DZUrjQs9cU9PFVsyvjGM9vd3UykkvbLfLhbRjQqhM4BhRFWM7eW has expired: block height exceeded.

When using the above method. So there is definitely something else that has to be done before I can declare a transaction final. Where can I read about it?

UPDATE 27.07.2022:

So yesterday I was getting something from

connection.confirmTransaction(
            {
              blockhash: latestBlockHash.blockhash,
              lastValidBlockHeight: latestBlockHash.lastValidBlockHeight,
              signature,
            }

Today it doesn't return anything. Just like that. good game well played. Looks like after some time I get:

Error: TransactionExpiredBlockheightExceededError: Signature 56767Ps4Fq4ZCaowEzPxPoNhSEECsw41MebNkSCEcx2ZnWmQr8aCQjTqnArSK7NeCqBXRUehNuiqQk2LRwhym73 has expired: block height exceeded.

So I guess the network is busy.

Follow-up after few minutes

https://solana.fm/tx/56767Ps4Fq4ZCaowEzPxPoNhSEECsw41MebNkSCEcx2ZnWmQr8aCQjTqnArSK7NeCqBXRUehNuiqQk2LRwhym73?cluster=devnet-solana

Transaction has been confirmed, finalized! SuccessFinalizedMaximum Confirmations Achieved!

Can someone explain that to me?

signAndSendTransaction(transaction) -> doesn't return any promise next connection.confirmTransaction -> return an error that blockheight was exceeded. Then after a while transaction gets included.

How am I supposed to handle this on the front-end...

Answer 1

Reasons that confirmTransaction might throw a block height exceeded error when, in fact, the transaction was confirmed:

• the signature is so old that it’s fallen out of the status cache. The confirm method does not search any further back in the ledger than that. Read more here.
• the signature was confirmed before you made the call to confirmTransaction, so the confirmation code ‘missed’ it. This is a known bug, tracked here.

When the block height passes without confirmTransaction having received a notification that the signature was confirmed, for one of the above reasons, you may receive a misleading BlockHeightExceeded error.