Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Echoing additional Device wrp fields in qos ack #286

Open
denopink opened this issue Jan 20, 2023 · 0 comments
Open

Feature: Echoing additional Device wrp fields in qos ack #286

denopink opened this issue Jan 20, 2023 · 0 comments
Assignees

Comments

@denopink
Copy link
Contributor

denopink commented Jan 20, 2023

Hey team, wanted to circle back to an older question from a chat with me, wes, shipla and sadhyama (screenshoot of the message attached)
When qos ack was implemented, the assumption was that we were not echoing the device rdr with talaria’s qos ack (currently set to 0).

talaria/ackDispatcher.go

Lines 90 to 92 in ad99cb3

// rdr of 0 is success https://xmidt.io/docs/wrp/basics/#request-delivery-response-rdr-codes
// Atm, there doesn't exist any conditions that'll cause a request delivery response to be a nonzero
var rdr int64 = 0

These are the following wrp fields we’re currently echoing from the device with talaria’s qos ack:

  • PartnerIDs
  • Headers
  • Metadata
  • SessionID
  • QualityOfService
  • TransactionUUID
  • Source as the qos ack’s Destination

https://xmidt.io/docs/wrp/simple-messages/#qos-details
We are currently omitting the content_type and payload.

talaria/ackDispatcher.go

Lines 107 to 134 in ad99cb3

r = &device.Request{
Message: &wrp.Message{
// When a qos field is specified that requires an ack, the response ack message SHALL be a msg_type=4.
Type: wrp.SimpleEventMessageType,
// The `source` SHALL be the component that cannot process the event further.
Source: d.hostname,
// The `dest` SHALL be the original requesting `source` address.
Destination: m.Source,
// The `content_type` and `payload` SHALL be omitted & set to empty, or may set to `application/text` and text to help describe the result. **DO NOT** process this text beyond for logging/debugging.
ContentType: "",
Payload: []byte{},
// The `partner_ids` SHALL be the same as the original message.
PartnerIDs: m.PartnerIDs,
// The `headers` SHOULD generally be the same as the original message, except where updating their values is correct.
Headers: m.Headers,
// The `metadata` map SHALL be populated with the original data or set to empty.
Metadata: m.Metadata,
// The `session_id` MAY be added by the cloud.
SessionID: dm.SessionID(),
// The `qos` SHALL be the same as the original message.
QualityOfService: m.QualityOfService,
// The `transaction_uuid` SHALL be the same as the original message.
TransactionUUID: m.TransactionUUID,
// The `rdr` SHALL be present and represent the outcome of the handling of the message.
RequestDeliveryResponse: &rdr,
},
Format: event.Format,
}

We're currently working out wether or not we want to echo the device’s RequestDeliveryResponse as well and if there any other fields we’ll like to echo in talaria’s qos ack.

@denopink denopink self-assigned this Jan 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant