You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The command/subsystem paradigm allows for a simulated parallel processing where you might have concurrent activities each initiated through separate events but interleaved in the logs. In other logging systems there is a transaction id that is included in the log so that you can see the flow and pull out only those events for the activity you care about. A contrived example To make my point would be intaking while manipulating the control panel. The transaction id could be generated from the initial action of the human operator. Something to consider adding if you feel it would help debugging.
I’d think that the transaction ID would be where the action is initiated. So if the operator initiates a climb then a transaction id would be acquired and used for all subsequent logging calls that follow directly from that action. Since the transaction id would need to be unique something in the logger should assign them. Or you could use utime() at the time of initiation or a random number although that won’t be sequential so maybe not as useful
The text was updated successfully, but these errors were encountered:
From my commentary on the logger changes
The command/subsystem paradigm allows for a simulated parallel processing where you might have concurrent activities each initiated through separate events but interleaved in the logs. In other logging systems there is a transaction id that is included in the log so that you can see the flow and pull out only those events for the activity you care about. A contrived example To make my point would be intaking while manipulating the control panel. The transaction id could be generated from the initial action of the human operator. Something to consider adding if you feel it would help debugging.
I’d think that the transaction ID would be where the action is initiated. So if the operator initiates a climb then a transaction id would be acquired and used for all subsequent logging calls that follow directly from that action. Since the transaction id would need to be unique something in the logger should assign them. Or you could use utime() at the time of initiation or a random number although that won’t be sequential so maybe not as useful
The text was updated successfully, but these errors were encountered: