SEP-6, 24, 31: add transaction status for discontinued transactions

[JakeUrban]

What problem does your feature solve?

Anchors may want to communicate to wallet application that specific in-progress transactions are no longer valid. For example, if a transaction is in pending_user_transfer_start for over X minutes, the anchor may want to consider this transaction abandoned by the user.

What would you like to see?

All SEPs that process transactions (6, 24, & 31), should have a status value that indicates to client-side applications that the transaction cannot be continued.

Status valid candidates:

• canceled
• invalid
• discontinued
• abondoned

cc @lijamie98

[lijamie98]

In the MGI meeting on 1/27/2022, MGI wish to show something like expired. I think we may add expired.

For invalid, when does that happen?

[JakeUrban]

The values I listed are just suggestions, we could use expired instead 👍

I can see a future where we have both expired and canceled though, since they indicate two different things. For now lets roll with expired.

[lijamie98]

Yes, that looks good.

In your original list, I thought you are going to add more of the statuses to SEP24. Should we add the others as well?

[JakeUrban]

The "status value candidates" list was just ideas for the name, I didn't mean to indicate that we should add all those as distinct status values.

[JakeUrban]

cc @accordeiro

We're currently considering two new statuses:

• expired: indicates that the user did not complete the interactive flow or did not deliver funds to the anchor within a timeframe defined by the anchor
• canceled: indicates that funds were delivered but the transaction was canceled for some reason. In this case, the refunded attribute (i.e. not a status value) should be true.

It sounds like we agree on expired. Regarding cancelled, there are some alternative suggestions:

• just use completed, but mark refunded as true. No need for an additional status.
  • The primary concern here is that the client needs to take 2 attributes into account.
• make refunded a status value and deprecate the refunded attribute.

[accordeiro]

I think we should make refunded a first-class status, since combining a refunded boolean flag with other statuses is confusing (like what does it mean to have refunded=true and status=pending_anchor)?

So I like the plan of adding the following statuses:

• expired
• cancelled
• refunded

And deprecating the boolean flag. Although I'm not sure how that flag is used in the wild, if at all.

[accordeiro]

I think we should think about this problem and #1122 together, since it touches the refund process.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 30 days unless the stale label is removed.

[JakeUrban]

Reopening this because #1222 did not address this issue. We added the refunded status value, but not the expired status.