Openbravo Issue Tracking System - POS2
View Issue Details
0049888POS2POSpublic2022-07-27 13:062024-05-27 16:11
asier_perez 
Retail 
normalmajorsometimes
closedno change required 
5
 
 
marvintm
No
No
0049888: Cash Up Error prevents from logging in after doing Cash Up, refresh page and trying to log in very quickly
When doing Cash Up and then refreshing the page and logging in quickly, sometimes the next error message appears: 'There are cashup errors in this terminal'. It prevents from logging in again until the error is deleted from the database or backend.

This is mainly due to application source code updates. When the source code is updated, the service-worker sends a message to the web to purge the state on refresh/login, that results in losing the local cashup, which allows us to work while we have errors in backend.
## Updated steps to reproduce
1. Login WebPOS and complete a cashup(if you can complete it with errors better).
2. (For this step we need to have cashup errors in backend). Open DevTools by pressing F12 and clean the application state to simulate a source update.
3. Refresh the application and login, you'll see the "there are cashup errors in the terminal" because the local state has been purged due to an application update.


## Original steps to reproduce
This error can be reproduced in live builds (POS2 with modules), and it could require several tries following the next steps.

0- Log in Web POS and leave a till open; this step prevents the Close Store dialog to appear later in POS2 and causes the cash up process to be faster, which is important to reproduce the error
1- Go to POS2 and log in
2- Do cash up normally and just after clicking on the 'Finish' button, press F5 to refresh the page
3- Repeat steps 1 and 2 until the error appears, preventing you to log in

Note: For now, it is not very clear what the timing is to press F5, and the error could not occur after several tries.
TBD: An option would be to not purge the state entirely or keep some things between version updates.
No tags attached.
? cashUpError.json (4,279) 2022-08-16 14:18
https://issues.openbravo.com/file_download.php?file_id=17398&type=bug
txt cashUpErrorMessage.txt (1,495) 2022-08-16 14:27
https://issues.openbravo.com/file_download.php?file_id=17399&type=bug
png cashup.png (30,773) 2023-03-14 17:26
https://issues.openbravo.com/file_download.php?file_id=18262&type=bug
png
Issue History
2022-07-27 13:06asier_perezNew Issue
2022-07-27 13:06asier_perezAssigned To => Retail
2022-07-27 13:06asier_perezFile Added: reproduceCashUpError.spec.js
2022-07-27 13:06asier_perezOBNetwork customer => No
2022-07-27 13:06asier_perezTriggers an Emergency Pack => No
2022-07-27 14:00asier_perezSummaryError when executing Cash Up Cypress tests several times => Cash Up Error prevents from logging in after doing Cash Up and trying to log in very quickly
2022-07-27 14:00asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24542#r24542
2022-07-27 14:00asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24544#r24544
2022-07-27 14:00asier_perezProposed Solution updated
2022-07-27 14:01asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24545#r24545
2022-07-27 14:03asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24546#r24546
2022-07-27 14:03asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24547#r24547
2022-07-27 14:04asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24548#r24548
2022-07-27 14:05asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24549#r24549
2022-07-27 14:07asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24550#r24550
2022-07-27 14:08asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24551#r24551
2022-07-28 09:34asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24552#r24552
2022-07-28 09:46asier_perezSeveritycritical => major
2022-07-28 09:46asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24555#r24555
2022-07-28 09:54asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24559#r24559
2022-07-28 09:54asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24560#r24560
2022-07-28 09:58asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24561#r24561
2022-07-28 10:21asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24562#r24562
2022-08-16 11:04asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=24606#r24606
2022-08-16 14:18asier_perezFile Added: cashUpError.json
2022-08-16 14:27asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24609#r24609
2022-08-16 14:27asier_perezFile Added: cashUpErrorMessage.txt
2022-08-16 14:29asier_perezDescription Updatedbug_revision_view_page.php?rev_id=24610#r24610
2022-11-28 16:04andre_montenegroSummaryCash Up Error prevents from logging in after doing Cash Up and trying to log in very quickly => Cash Up Error prevents from logging in after doing Cash Up, refresh page and trying to log in very quickly
2022-11-28 16:04andre_montenegroDescription Updatedbug_revision_view_page.php?rev_id=25176#r25176
2023-03-14 17:25asier_perezDescription Updatedbug_revision_view_page.php?rev_id=25698#r25698
2023-03-14 17:25asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=25699#r25699
2023-03-14 17:25asier_perezFile Deleted: reproduceCashUpError.spec.js
2023-03-14 17:26asier_perezFile Added: cashup.png
2023-03-14 17:29asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=25700#r25700
2023-03-14 17:35asier_perezSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=25701#r25701
2023-05-04 17:04AugustoMauchAssigned ToRetail => cberner
2023-05-18 17:53cbernerDescription Updatedbug_revision_view_page.php?rev_id=26093#r26093
2023-05-18 17:53cbernerSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=26094#r26094
2023-05-18 17:53cbernerProposed Solution updated
2024-04-11 13:37asier_perezSeveritymajor => critical
2024-05-07 15:58lorenzofidalgoTarget Version => 24Q2
2024-05-27 10:36AugustoMauchNote Added: 0165153
2024-05-27 10:36AugustoMauchAssigned Tocberner => Retail
2024-05-27 10:36AugustoMauchTypedefect => design defect
2024-05-27 10:36AugustoMauchSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=28033#r28033
2024-05-27 10:36AugustoMauchStatusnew => acknowledged
2024-05-27 12:24guillermogilSeveritycritical => major
2024-05-27 12:24guillermogilTarget Version24Q2 =>
2024-05-27 16:07marvintmStatusacknowledged => scheduled
2024-05-27 16:11marvintmReview Assigned To => marvintm
2024-05-27 16:11marvintmNote Added: 0165176
2024-05-27 16:11marvintmStatusscheduled => closed
2024-05-27 16:11marvintmResolutionopen => no change required

Notes
(0165153)
AugustoMauch   
2024-05-27 10:36   
This issue has been changed to Design Defect and reassigned to Retail because:
- When sources are updated, the infra removes the local state, as it can be inconsistent with the updated sources.
- As a consequence, in order to initialize the cashup, there is some POS business logic that tries to initialize the cashup from the backend, something that cannot happen because there were cashups in error

From the infra point of view, resetting the state when sources are updated makes sense. This either will keep working like it is, or the POS team can think of doing something to initialize the cashup even when it is not possible to do it from the backend
(0165176)
marvintm   
2024-05-27 16:11   
This is actually the expected behavior.

There are two things to consider:
- First, when a new version of Openbravo is deployed, we cannot guarantee that the local state in the POS will be compatible with the new sources. Therefore, we need to reset it, and as part of this reset, the POS will have to reload the Cashup information from the backend.

- Second, it is not possible for the POS to load a reliable version of the Cashup information if there are Errors While Importing pending to be resolved in the backend.

For these two reasons, it is very important to understand that there should never be Errors While Importing pending to be solved when a new version of OB is deployed. EWIs should never be considered a "normal" thing to exist in an production instance, they should always be solved whenever they appear, but particularly after a deployment it is an extremely important point to consider.

Both CSU and Services teams are aware about this, and reviewing pending EWIs is part of the basic tasks they need to perform before a deployment is done.