A couple of meetings ago, I noticed a couple of check-outs were not being shown until the "undo" window had passed. This occurred when I was rapidly checking-out multiple students, so the additional stress probably broke the system somehow.
Honestly, the current client-side check-in/check-out architecture, especially the "pending changes" concept in the student service, is all a bit hacky and fragile. I think it would be best to just redesign this feature in a more robust manner, with a server-side undo mechanism instead of the current client-side delayed submission approach.
Server-side undo would have a couple of notable benefits:
If the client app is closed or crashes during the undo window, the attendance event will not be lost.
When multiple clients are simultaneously entering attendance events, the events will be reflected across all devices as soon as they are entered (or, at least within the client poll window).
A couple of meetings ago, I noticed a couple of check-outs were not being shown until the "undo" window had passed. This occurred when I was rapidly checking-out multiple students, so the additional stress probably broke the system somehow.
Honestly, the current client-side check-in/check-out architecture, especially the "pending changes" concept in the student service, is all a bit hacky and fragile. I think it would be best to just redesign this feature in a more robust manner, with a server-side undo mechanism instead of the current client-side delayed submission approach.
Server-side undo would have a couple of notable benefits: