Openbravo Issue Tracking System - POS2 | |||||||||||||||||||
| View Issue Details | |||||||||||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||||||||
| 0050552 | POS2 | Core | public | 2022-10-17 11:30 | 2022-11-07 13:55 | ||||||||||||||
| Reporter | AugustoMauch | ||||||||||||||||||
| Assigned To | cberner | ||||||||||||||||||
| Priority | normal | Severity | critical | Reproducibility | sometimes | ||||||||||||||
| Status | closed | Resolution | fixed | ||||||||||||||||
| Platform | OS | 5 | OS Version | ||||||||||||||||
| Product Version | |||||||||||||||||||
| Target Version | Fixed in Version | 23Q1 | |||||||||||||||||
| Merge Request Status | |||||||||||||||||||
| Review Assigned To | |||||||||||||||||||
| OBNetwork customer | |||||||||||||||||||
| Support ticket | |||||||||||||||||||
| Regression level | |||||||||||||||||||
| Regression date | |||||||||||||||||||
| Regression introduced in release | |||||||||||||||||||
| Regression introduced by commit | |||||||||||||||||||
| Triggers an Emergency Pack | No | ||||||||||||||||||
| Summary | 0050552: Cashup is not properly persisted between a day and the next | ||||||||||||||||||
| 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. | ||||||||||||||||||
| 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. | ||||||||||||||||||
| Proposed Solution | Add missing awaits in posthooks of FinishCashup. Add log in logout function to make sure we are using the persisted cashupId and not another id. | ||||||||||||||||||
| Additional Information | |||||||||||||||||||
| Tags | No tags attached. | ||||||||||||||||||
| Relationships |
| ||||||||||||||||||
| Attached Files | |||||||||||||||||||
| Issue History | |||||||||||||||||||
| Date Modified | Username | Field | Change | ||||||||||||||||
| 2022-10-17 11:30 | AugustoMauch | New Issue | |||||||||||||||||
| 2022-10-17 11:30 | AugustoMauch | Assigned To | => Triage Platform Base | ||||||||||||||||
| 2022-10-17 11:30 | AugustoMauch | Triggers an Emergency Pack | => No | ||||||||||||||||
| 2022-10-17 11:30 | AugustoMauch | Status | new => scheduled | ||||||||||||||||
| 2022-10-26 13:28 | hgbot | Note Added: 0142599 | |||||||||||||||||
| 2022-10-26 14:01 | cberner | Summary | Unexpected management of error leads to state inconsistency => Cashup is not properly persisted between a day and the next | ||||||||||||||||
| 2022-10-26 14:01 | cberner | Description Updated | bug_revision_view_page.php?rev_id=24988#r24988 | ||||||||||||||||
| 2022-10-26 14:01 | cberner | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=24990#r24990 | ||||||||||||||||
| 2022-10-26 14:01 | cberner | Proposed Solution updated | |||||||||||||||||
| 2022-10-27 13:31 | hgbot | Resolution | open => fixed | ||||||||||||||||
| 2022-10-27 13:31 | hgbot | Status | scheduled => closed | ||||||||||||||||
| 2022-10-27 13:31 | hgbot | Note Added: 0142653 | |||||||||||||||||
| 2022-10-27 13:31 | hgbot | Fixed in Version | => 23Q1 | ||||||||||||||||
| 2022-10-27 13:31 | hgbot | Note Added: 0142654 | |||||||||||||||||
| 2022-11-07 13:55 | cberner | Assigned To | Triage Platform Base => cberner | ||||||||||||||||
| Notes | |||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||
|
|
|||||
|
|
||||