Project:
| View Revisions: Issue #50552 | [ Back to Issue ] | ||
| Summary | 0050552: Cashup is not properly persisted between a day and the next | ||
| Revision | 2022-10-26 14:01 by cberner | ||
| Steps To Reproduce | It happens after cashup finishes and on login the next day. After a lot of trials, we don't have a proper way to reproduce it yet. | ||
| Revision | 2022-10-26 14:01 by cberner | ||
| Description | When executing a cashup, sometimes it is not properly persisted and when logging we still have the previous cashup id. A possible reason is that several state actions are executed as posthooks to FinishCashup user action, and as such may have initial state distinct to that of the persisted finished cashup. Some awaits are even missing from async user actions. ## Original description We have noticed that if there is an error during the execution of a state action, sometimes that error is not properly managed. For instance, both the DeleteTicket and the CompleteTicket action execute the newTicket function to create a new ticket after deleting/completing the current one. Note that both action will send a synchronization message to the backend to create an order (with qty 0 if the order was deleted). If we force an error on the newTicket function (i.e. by executing null.x) one of these two secuences of events will take place: - The error will be logged in in the console, in the terminal log and in a notification to the user. The state remains as it was before the action was executed, the ticket is still displayed to the user. No synchronization message is sent to the backend, no order is created. - The error is not logged anywhere (console, terminal log, notification). The state remains as it was before the action was executed, the ticket is still displayed to the user. A synchronization message is sent to the backend, an order will be created. The second case only happens rarely, but when it does it will result on duplicated tickets being sent to the backend, because if the user is still working in the frontend with a ticket that has already been processed in the backend. |
||
| Revision | 2022-10-26 13:28 by cberner | ||
| Steps To Reproduce | TO BE DONE | ||
| Revision | 2022-10-26 13:28 by cberner | ||
| Description | We have noticed that if there is an error during the execution of a state action, sometimes that error is not properly managed. For instance, both the DeleteTicket and the CompleteTicket action execute the newTicket function to create a new ticket after deleting/completing the current one. Note that both action will send a synchronization message to the backend to create an order (with qty 0 if the order was deleted). If we force an error on the newTicket function (i.e. by executing null.x) one of these two secuences of events will take place: - The error will be logged in in the console, in the terminal log and in a notification to the user. The state remains as it was before the action was executed, the ticket is still displayed to the user. No synchronization message is sent to the backend, no order is created. - The error is not logged anywhere (console, terminal log, notification). The state remains as it was before the action was executed, the ticket is still displayed to the user. A synchronization message is sent to the backend, an order will be created. The second case only happens rarely, but when it does it will result on duplicated tickets being sent to the backend, because if the user is still working in the frontend with a ticket that has already been processed in the backend. |
||
| Copyright © 2000 - 2009 MantisBT Group |
 |