Openbravo Issue Tracking System - POS2 |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0050554 | 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 | 22Q3.2 | Fixed in Version | 22Q3.2 | |
| Merge Request Status | approved |
| Review Assigned To | |
| OBNetwork customer | No |
| Support ticket | |
| Regression level | |
| Regression date | |
| Regression introduced in release | |
| Regression introduced by commit | |
| Triggers an Emergency Pack | No |
|
| Summary | 0050554: Unexpected management of error leads to state inconsistency |
| 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 | TO BE DONE |
| Proposed Solution | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | blocks | defect | 0050552 | | closed | cberner | Cashup is not properly persisted between a day and the next |
|
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2022-10-17 11:30 | AugustoMauch | Type | defect => backport |
| 2022-10-17 11:30 | AugustoMauch | Target Version | => 22Q3.2 |
| 2022-10-27 13:34 | hgbot | Merge Request Status | => open |
| 2022-10-27 13:34 | hgbot | Note Added: 0142657 | |
| 2022-10-27 13:58 | hgbot | Merge Request Status | open => approved |
| 2022-10-27 13:59 | hgbot | Resolution | open => fixed |
| 2022-10-27 13:59 | hgbot | Status | scheduled => closed |
| 2022-10-27 13:59 | hgbot | Fixed in Version | => 22Q3.2 |
| 2022-10-27 13:59 | hgbot | Note Added: 0142661 | |
| 2022-10-27 13:59 | hgbot | Note Added: 0142662 | |
| 2022-11-07 13:55 | cberner | Assigned To | Triage Platform Base => cberner |