|View Issue Details|
|Type||Category||Severity||Reproducibility||Date Submitted||Last Update|
|design defect||[Retail Modules] Web POS||minor||have not tried||2019-10-15 18:45||2020-03-18 09:50|
|Priority||normal||Resolution||open||Fixed in Version|
|Status||scheduled||Fix in branch||Fixed in SCM revision|
|OS Version||Database version||Ant version|
|Product Version||SCM revision|
|Review Assigned To|
|Regression introduced in release|
|Regression introduced by commit|
|Triggers an Emergency Pack||No|
0042034: External Orderloader import_entry processed in asynchronous mode stays in 'Initial' status for ever
|Description||In 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 Reproduce||Send a external order loader in asynchronous mode. You will see that the import_entry is not processed never.|
|Tags||No tags attached.|
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.
|2019-10-15 18:45||ALopetegui||New Issue|
|2019-10-15 18:45||ALopetegui||Assigned To||=> Retail|
|2019-10-15 18:45||ALopetegui||Triggers an Emergency Pack||=> No|
|2020-02-25 16:33||kchoperena||Resolution time||=> 1583794800|
|2020-02-27 23:47||rqueralta||Assigned To||Retail => rqueralta|
|2020-02-27 23:47||rqueralta||Status||new => scheduled|
|2020-03-11 12:58||ALopetegui||Severity||major => minor|
|2020-03-11 12:58||ALopetegui||Type||defect => design defect|
|2020-03-18 09:50||marvintm||Resolution time||1583794800 =>|
|2020-03-18 09:50||marvintm||Note Added: 0118666|
|Copyright © 2000 - 2009 MantisBT Group|