feat: [MR-552] Define RejectCode::SysUnknown and error codes

[alin-at-dfinity]

[MR-552] Define new RejectCode variant SysUnknown (for when the response to a best-effort call is unknown) and two ErrorCode variants -- DeadlineExpired and ResponseDropped -- to be used when expiring best-effort calls or, respectively, when dropping best-effort responses.

[alin-at-dfinity]

Technically, we should also have a new certification version to go along with it (e.g. V19 does not support SysUnknown, V20 does), but the value is encoded as a plain u8, so it would basically only be "forward compatibility theater": i.e. it would only serve as a marker for "support for this needs to roll out to all subnets before it can be enabled on any subnet" (or the other way around).

I can do it, but it's definitely not necessary in any way. WDYT?

[rumenov]

@alin-at-dfinity one car argue that DeadlineExpired and ResponseDropped are SysTransient, right?

[stiegerc]

RejectCode is included in the reject response. The canister can access it using this. I wonder whether this provides any useful information from the point of view of a canister, i.e. what does SysUnknown tell me that SysTransient doesn't in terms of how I should react?

I see you also defined new ErrorCode variants, which are use for the execution history. But we could also map those to SysTransient right?

[derlerd-dfinity]

@rumenov, @stiegerc we decided against using SysTransient because Unknown means it might not be safe to blindly retry (as the message might have reached the target canister and was successfully executed) whereas Transient means it is safe to blindly retry [it is a separate, unrelated discussion whether or not blindly retrying is a good idea from an application perspective].

[derlerd-dfinity]

Code wise the change LGTM.

I'd suggest to wait a bit to see whether there are strong objections against this new reject code based on the questions/discussions above.

[oggy-dfin]

LGTM, is in line with the proposed interface spec change

[oggy-dfin]

One thing I don't know is if we're still maintaining the list of error codes - it's definitely gotten stale, but if we want to maintain it, we should add these codes there at some point.

[stiegerc]

@rumenov, @stiegerc we decided against using SysTransient because Unknown means it might not be safe to blindly retry (as the message might have reached the target canister and was successfully executed) whereas Transient means it is safe to blindly retry [it is a separate, unrelated discussion whether or not blindly retrying is a good idea from an application perspective].

Ah I see, makes sense.

[rumenov]

as the message might have reached the target canister and was successfully executed

Why if the message was successfully executed it cannot be retried ?

[stiegerc]

as the message might have reached the target canister and was successfully executed

Why if the message was successfully executed it cannot be retried ?

It can but it may still be important information for the canister that the message may have arrived, whereas with SysTransient you know for sure that it didn't. It stands to reason that you should use a guaranteed reply message for this kind of thing but that's a different discussion.