So at the moment transaction statuses are based off the fields accepted and success in the receipt, with the following logic:

 let status_code =
            if receipt.accepted.is_some() && receipt.accepted.unwrap() && receipt.success {
                TxnStatusCode::Confirmed // 3
            } else if receipt.success {
                TxnStatusCode::Dispatched // 1
            } else {
                let errors: Vec<ScillaError> =
                    receipt.errors.into_iter().flat_map(|(_k, v)| v).collect();
                if errors.len() == 1 {
                    match errors[0] {
                        ScillaError::CallContractFailed => TxnStatusCode::FailScillaLib,
                        ScillaError::CreateContractFailed => TxnStatusCode::Error,
                        ScillaError::GasNotSufficient => TxnStatusCode::InsufficientGas,
                        ScillaError::BalanceTransferFailed => TxnStatusCode::InsufficientBalance,
                        _ => TxnStatusCode::Error,
                    }
                } else {
                    TxnStatusCode::Error
                }
            };

So in this case, if a status of 1 is being returned, this implies that either accepted==None or accepted==Some(false).
So I guess the answer is to just ignore the accepted field and return 3 if receipt.success or an error otherwise?
Does that sound like the correct behaviour @DrZoltanFazekas?

IMO, TxnStatusCode::Confirmed i.e. status code 3 is the final state meaning that the transaction got included into a block (which is instantly final on ZQ1). I don't think receipt.accepted represents this state, does it?

Based on the description in the docs, status code 2 is the same as pending in the EVM world (transaction is in the mempool and can be included in the next block) and status code 4 the same as queued (transaction is in the mempool but can't be included in the next block because of a nonce gap).

I'm not sure if TxnStatusCode::Dispatched is implemented correctly either. AFAIK receipt.success means the same as status = 0x1 in the EVM transaction receipt i.e. the transaction did not revert. Is that the right condition for the status code 1?

I tried to look up the semantics of these fields and codes in the old Zilliqa 1 dev docs, but it was not as helpful as I expected: https://dev.zilliqa.com/zilliqa1/developers/transaction-lifecycle/dev-txn-receipt/

Sorry I put in the pull request before I saw your reply.
I don't know the intentions of the fields in the receipt. @JamesHinshelwood might, it looks like he added the accepted field 9 months ago, but the success field 2 years ago, so the meanings could definitely have drifted since then though.
I've had a look online to see how other people define this sort of things but I've seen documentation that says things like "status (integer): Either 1 (success) or 0 (failure)." So that doesn't shed much light.

If you take a look in PR #2170 I've dropped support for TxnStatusCode::Dispatched entirely, and I'm basically just reporting TxnStatusCode::Confirmed unless there's a specific reason not to. It sounds like this is a bit over-optimistic, and we should actually be adding code to specifically query whether the transaction's block is finalised, and reporting 2 before it is finalised and 3 after, unless there's any error?

success in a Zilliqa receipt means "did the transaction revert?"
accepted means "did the 'to address' receive any ZIL as a result of this transaction?"

So that sounds like the previous implementation was correct? We should be returning Confirmed (3) if and only if accepted==Some(true)?

I've just noticed the discussion on Slack and that appears to support that?

Where is the discussion on Slack?

My understanding of success was correct i.e. it has nothing to do with status code 1 (Dispatched). A transaction that reverts can also be dispatched and even included in a block i.e. become confirmed.

Thanks for clarifying the meaning of accepted @JamesHinshelwood. If I understood correctly, it only stores whether the recipient of the transaction accepted any ZIL sent by the sender i.e. it has nothing to do with the status code 3 (Confirmed).

I'll send an invite to discuss how to handle these legacy status codes inherited from Zilliqa 1 @maxconway @JamesHinshelwood

Yep good idea re a discussion on this.
The Slack discussion I was referencing was the one with Mark Carrol - if I understand correctly he was asking about the receipt.status field in eth_getTransactionReceipt, which is just a renaming of the receipt.success we're discussing here

Just for reference, I've traced through where these fields in the receipt are used:

AFAICS, receipt.success is used in:

• The GetTransactionStatus endpoint we're discussing here
• Other APIs where the receipt is returned
• The db where it's stored
• consensus.rs where it's set based on apply_result.success()
• computing the transaction receipt's hash
• The converter, where its set based on transaction.receipt.success

So its semantics are only relevant in terms of being produced by the converter and apply_result.success() in consensus.rs and consumed by APIs.

receipt.accepted is used in exactly the same way - produced by the converter and consensus.rs and consumed by the APIs, with the addition of also being used to set the modification_state field in GetTransactionStatus, though much like this one I guessed a bit at what that should represent.

New statuses will be:

| modificationState | status | Description                                                             |
| ------------------- | -------- | ----------------------------------------------------------------------- |
| 0                   | 1        | Pending in mempool or in a non-finalized block    |
| 2                   | 3        | in a finalized block    |
| 2                   | 255      | error                                            |