FreeEMS Issues - Tunix
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000423TunixFreeEMS Pluginpublic2011-11-26 00:282012-04-01 17:10
ReporterFred 
Assigned ToToxicGumbo 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusassignedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version 
FirmwareVersion
Summary0000423: Improve Error Handling Flow/Semantics
DescriptionQuote:

"If a location ID requires a full write, right now, mtx has no way to know that it does, thus mtx will get stuck in a loop right now, as if it tries a partial write to a full write page, and you return and error, megatunix doesn't know how to handle that and will just keep retrying over and over and over again."

Irrespective of the full/partial write issue, which we'll discuss and solve another day, this flow is a little broken.

It's necessary to distinguish between different types of failures to perform the action inside the application. There are at least two failure modes, possibly more:

 - Packet timeout
 - Error response

The former should resend if the packet is one that requires guaranteed delivery (not a datalog request).

The latter should simply give up and preset the error to the user to deal with, either by correcting their actions based on the message or alerting you to the incompatibility. The fact that you get an error response back implies that something was wrong with what you sent, either by the application's design, or by the users action. Unless you explicitly handle each error code with custom actions you can't reasonably expect to do anything other than show the user the error and move on.

Certainly looping when the device is TELLING you that something is wrong is not a wise behaviour choice.

The only really correct thing to do in all cases when receiving a specific error code back from the firmware is to display that code, with or without a message, to the user in an obvious way. Synchronous errors should be sufficiently rare to always pop up a message for, or at least bring an error list window such as the one visible in the picture below to the front of the screen to grab attention.

http://www.ectune.com/Portals/0/screenshot2.png [^]

This is strongly related to issue 0000251 in which I didn't know the full extent of the problem.

Asynchronous errors will need a different mechanism as there is the potential for those to come in a flood.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files

Notes
(0000708)
dandruczyk   
2011-11-26 13:20   
Due to your comms design Everything is asynchronous. Correction, mtx wont loop on error only timeout. You'd know this if you used it more. Error wimdow is pending however i am holding back due to the flames i get over any popups no matter how dismissable i make them...
(0000710)
Fred   
2011-11-26 14:10   
You're right, let me test what it does and whether you let me do invalid things or not. One moment please.
(0000711)
Fred   
2011-11-26 14:22   
http://issues.freeems.org/view.php?id=428 [^]

For a start! :-)

This can stay open until you clarify that either your earlier statement is wrong, and it doesn't do what you said in a loop, or the behaviour is fixed.
(0001356)
dandruczyk   
2012-04-01 16:53   
linked to issue is closed, hence it appears this should be closed
(0001360)
Fred   
2012-04-01 17:10   
Jeff, any chance of testing this? If you need clarification, just ask. If you don't have time, send it back my way and I'll have a play at some point. Thanks.