Openbravo Issue Tracking System - Retail Modules
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0042034Retail ModulesWeb POSpublic2019-10-15 18:452022-08-19 15:03
ReporterALopetegui 
Assigned Torqueralta 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusscheduledResolutionopen 
PlatformOS5OS Version
Product Version 
Target VersionFixed 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 PackNo
Summary0042034: External Orderloader import_entry processed in asynchronous mode stays in 'Initial' status for ever
DescriptionIn one client we had an import_entry in status Initial all the time, because somehow the external orderloader was sent in asynchronous mode and the run() function in this mode is empty, for that reason even if the import_entry_manager, wants to process the import_entry, it doesn't do anything and the import entry continues in status 'Initial' for ever. Besides, there is always one thread occupied trying to process that entry, but it can't finish.
How that external orderleader was sent in different way is unclear, because all external orderloader before and after that entry was processed normally in synchronous mode. To workaround this problem in the client we change manually the importstatus='Error'.
Steps To ReproduceSend a external order loader in asynchronous mode. You will see that the import_entry is not processed never.
Proposed Solution
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2019-10-15 18:45ALopeteguiNew Issue
2019-10-15 18:45ALopeteguiAssigned To => Retail
2019-10-15 18:45ALopeteguiTriggers an Emergency Pack => No
2020-02-25 16:33kchoperenaResolution time => 1583794800
2020-02-27 23:47rqueraltaAssigned ToRetail => rqueralta
2020-02-27 23:47rqueraltaStatusnew => scheduled
2020-03-11 12:58ALopeteguiSeveritymajor => minor
2020-03-11 12:58ALopeteguiTypedefect => design defect
2020-03-18 09:50marvintmResolution time1583794800 =>
2020-03-18 09:50marvintmNote Added: 0118666
2022-08-19 15:03ivancaceresIssue Monitored: ivancaceres

Notes
(0118666)
marvintm   
2020-03-18 09:50   
After further discussion, we consider this a design defect.

Currently the ExternalOrderLoader creates the import entry in initial status and then commits the transaction, and after that continues with the process. If the process ends correctly, it then changes the import entry to Success status, and otherwise it changes it to Error.

The import entries were left in Initial status in this case because the customer environment was suffering a problem, and the database ran out of available connections at some point. This meant that the import entries had been created, the process then failed, and as there were no available connections, it could not change them to Error status.

Therefore, the problem could be avoided simply by removing the commit that creates the import entry, so that if the same problem happens the import entries would not be created, or would be left in error.

However, the commit is there for a reason: it was added to prevent cases of duplicated requests adding unnecessary work to the server, and even more, to prevent very ugly cases of integrations with external systems being executed twice.

Therefore, we currently believe that the potential risk of doing this change doesn't offset the small benefit of avoiding this quite harmless problem that so far has happened only twice, and that has the very simple solution of just removing the generated import entries manually.