lorawan-stack
lorawan-stack copied to clipboard
Network Server scheduling attempt events should be merged
Summary
Network Server scheduling attempts (ns.down.data.schedule.fail, ns.down.data.schedule.success and ns.down.data.schedule.attempt) should be merged into singular events instead of one event per scheduling attempt.
Current Situation
The Network Server will generate an attempt/fail/success event per scheduling attempt. In the worst case, this means that if we have to try 10 gateways in order to schedule a downlink we will have 10 attempt events, 9 fail events and 1 success event.
While for us this may make sense (or rather, we can convince ourselves as maintainers that this is sane), it it very confusing for a end user to parse. End users see a fail event and assume the whole downlink was completely failed, while in reality we probably had some failed attempts but succeeded later on.
Why do we need this? Who uses it, and when?
If we merge these events as much as possible:
- We emit less events overall with bigger payloads. Overhead wise this is more optimal for everyone.
- Users get to see a simplified
success/failresponse, which is what they are interested in. - The NOC may have an easier time dealing with these events without having to correlate them.
Proposed Implementation
We change the data type for the success/failure events to contain in a single message:
- All of the attempt requests.
- All of the failed attempts.
- All of the successful attempts.
Contributing
- [X] I can help by doing more research.
- [X] I can help by implementing the feature after the proposal above is approved.
- [X] I can help by testing the feature before it's released.
Code of Conduct
- [X] I agree to follow TTN's Community Code of Conduct.
We should also take a look at the scheduling event error propagation. Right now the cause is determined by the error code of the returned errors, and we probably should propagate these errors too.