Openbravo Issue Tracking System - Retail Modules | |||||
| View Issue Details | |||||
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0053279 | Retail Modules | Web POS | public | 2023-08-24 08:50 | 2023-09-15 13:21 |
| Reporter | joniturralde93 | ||||
| Assigned To | Retail | ||||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | new | Resolution | open | ||
| Platform | OS | 5 | OS Version | ||
| Product Version | |||||
| Target Version | Fixed in Version | ||||
| 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 | 0053279: connectRFIDDevice and disconnectRFIDDevice execution order | ||||
| Description | Those RFID functions have no warranty to be finished at the same time they are called. As both of them send the command through the websocket as a callback of the "waitForAck" function, if you execute one of them and immediately after the other one, it is possible that the commands are sent to the HWM in the incorrect order due to asynchronicity | ||||
| Steps To Reproduce | - In our case, the customer is using a custom RFID integration, UPOS RFID, but the problem happens in the standard RFID functions of rfidWebSocket. - Due to very quick user actions, we execute disconnectRFIDDevice and then connectRFIDDevice almost at the same time. - Disconnect executes waitForAck, then connect executes it also, but the callback of connect starts earlier (randomly). In that case, we first send the connect command and later the disconnect command to the hardware manager, which is incorrect and can lead to the RFID device being paused when it should be enabled and vice versa. | ||||
| Proposed Solution | Implement a way to ensure that the order of the function calls corresponds to the order which we send the commands to HWM, maybe a queue system, or even discarding commands if the last received call is oposed to the one being executed (to be analyzed). | ||||
| Additional Information | |||||
| Tags | No tags attached. | ||||
| Relationships | |||||
| Attached Files | |||||
| Issue History | |||||
| Date Modified | Username | Field | Change | ||
| 2023-08-24 08:50 | joniturralde93 | New Issue | |||
| 2023-08-24 08:50 | joniturralde93 | Assigned To | => Retail | ||
| 2023-08-24 08:50 | joniturralde93 | Triggers an Emergency Pack | => No | ||
| 2023-09-04 15:31 | ranjith_qualiantech_com | Assigned To | Retail => ranjith_qualiantech_com | ||
| 2023-09-15 13:21 | guillermogil | Assigned To | ranjith_qualiantech_com => Retail | ||
| 2023-09-15 13:21 | guillermogil | Type | defect => design defect | ||
| There are no notes attached to this issue. |