Anonymous | Login
Project:
RSS
  
News | My View | View Issues | Roadmap | Summary

View Issue Details[ Jump to Notes ] [ Issue History ] [ Print ]
ID
0050552
TypeCategorySeverityReproducibilityDate SubmittedLast Update
defect[POS2] Corecriticalsometimes2022-10-17 11:302022-11-07 13:55
ReporterAugustoMauchView Statuspublic 
Assigned Tocberner 
PrioritynormalResolutionfixedFixed in Version23Q1
StatusclosedFix in branchFixed in SCM revision
ProjectionnoneETAnoneTarget Version
OSAnyDatabaseAnyJava version
OS VersionDatabase versionAnt version
Product VersionSCM revision 
Merge Request Statusapproved
Review Assigned To
OBNetwork customerNo
Support ticket
Regression level
Regression date
Regression introduced in release
Regression introduced by commit
Triggers an Emergency PackNo
Summary

0050552: Cashup is not properly persisted between a day and the next

DescriptionWhen 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 ReproduceIt 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 SolutionAdd missing awaits in posthooks of FinishCashup.

Add log in logout function to make sure we are using the persisted cashupId and not another id.
TagsNo tags attached.
Attached Files

- Relationships [ Relation Graph ] [ Dependency Graph ]
depends on backport 005055322Q4.1 closedcberner Unexpected management of error leads to state inconsistency 
depends on backport 005055422Q3.2 closedcberner Unexpected management of error leads to state inconsistency 

-  Notes
(0142599)
hgbot (developer)
2022-10-26 13:28

 Merge Request created: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/1314 [^]
(0142653)
hgbot (developer)
2022-10-27 13:31

 Merge request merged: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/merge_requests/1314 [^]
(0142654)
hgbot (developer)
2022-10-27 13:31

 Directly closing issue as related merge request is already approved.

Repository: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2 [^]
Changeset: d248f16a1ef07fe062e53fcc25e8afa14f8c0ca3
Author: Cristian Berner <cristian.berner@openbravo.com>
Date: 27-10-2022 13:11:36
URL: https://gitlab.com/openbravo/product/pmods/org.openbravo.pos2/-/commit/d248f16a1ef07fe062e53fcc25e8afa14f8c0ca3 [^]

Fixes ISSUE-50552: Add missing awaits for cashup posthooks and some extra log

Adds useful log on entering the logout user-action and when finishing it, the current state
cashup id and the previously persisted one are logged.

---
M web-jspack/org.openbravo.pos2/src/model/session/Session.js
M web-jspack/org.openbravo.pos2/src/model/user-interface/__test__/FinishCashupUserAction.test.js
M web-jspack/org.openbravo.pos2/src/model/user-interface/user-actions/cashup/CashupUtils.js
M web-jspack/org.openbravo.pos2/src/model/user-interface/user-actions/cashup/FinishCashup.js
M web-jspack/org.openbravo.pos2/src/model/user-interface/user-actions/initialCount/ClearInitialCountInProgress.js
---

- 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 OBNetwork customer => No
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 Merge Request Status => open
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 View Revisions
2022-10-26 14:01 cberner Steps to Reproduce Updated View Revisions
2022-10-26 14:01 cberner Proposed Solution updated
2022-10-27 13:25 hgbot Merge Request Status open => approved
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

Copyright © 2000 - 2009 MantisBT Group
Powered by Mantis Bugtracker