Minimal implementation of Portal ping payload extensions spec #3010
Conversation
| case customPayload.`type` | ||
| of CapabilitiesType: |
There was a problem hiding this comment.
The way currently decoding + actions taken + encoding is put all together is not very modular (and that also becomes visible in tests).
I'll probably change this to have an object variant for this. I'd have to use a enum with different numbers however than the current numbers used for the types. But that is probably better anyhow so that there are no holes. (It does mean that full range cannot be covered, but that should be fine as realistically that range should not be hit)
| let customPayload = decodeSsz( | ||
| pong.customPayload.asSeq(), CustomPayloadExtensionsFormat | ||
| ).valueOr: | ||
| return err("Pong message contains invalid custom payload") | ||
|
|
||
| if customPayload.`type` != CapabilitiesType: | ||
| return err("Pong message contains invalid custom payload") | ||
|
|
||
| let payload = decodeSsz(customPayload.payload.asSeq(), CapabilitiesPayload).valueOr: | ||
| return err("Pong message contains invalid CapabilitiesPayload") |
There was a problem hiding this comment.
Very minimal version and does not decode anything else than CapabilitiesPayload, which is fine for now as that is the only one we send also.
| let customPayload = decodeSsz( | ||
| encodedCustomPayload.asSeq(), CustomPayloadExtensionsFormat | ||
| ).valueOr: | ||
| # invalid custom payload format, send back FailedToDecodePayload | ||
| return encodeErrorPayload(ErrorCode.FailedToDecodePayload) |
There was a problem hiding this comment.
We might be able to get away with this part if the spec gets changed to have the type and the payload directly in the ping/pong message
No description provided.