Does not correctly display the status in the process (the list is different) and did not write off the goods, although the "type" moved to the stage

In general, the problem is basically obvious. This happens when mysql doesn't have time to process queries quickly and locks tables, at these moments it gives a DEADLOCK error or something similar to has gone away . And some of the data (like the status transition history) may simply not be inserted into the database. solved in 2 ways 1) increase server power 2) enable MYSQL safe mode, which will give you an error on the screen if any of the tables it needs is locked at the moment I have included point 2 for you

[quote] Ustimenko Igor OneBox CTO wrote: In general, the problem is basically obvious. This happens when mysql doesn't have time to process queries quickly and locks tables, at these moments it gives a DEADLOCK error or something similar to has gone away . And some of the data (like the status transition history) may simply not be inserted into the database. It is solved in 2 ways 1) increasing the power of the server 2) enabling the MYSQL safe mode, which will give you an error on the screen if any of the tables it needs is locked at the moment, I included item 2 for you [/quote] 1. What specifically needs to be upgraded on the server (RAM, processor)? 2. Do I have some complex business processes (transfer subtasks to the required statuses and send the status to the socket for subtasks) that the server cannot work them out to the end? 3. Why was there not enough power to write off the goods, but enough to transfer them to the finishing status, despite the fact that this is the last thing the system should do? 4. Why did a problem arise for a process that had 3 subprocesses, but did not previously arise for a process that had 14 subprocesses?

1. I do not do free analytics of your server to answer this question 2. No, I don't think so 3. The table could be locked by another process (in the background, for example, by cron) 4. No difference how many subprocesses

[quote] Ustimenko Igor OneBox CTO wrote: 3. The table could be locked by another process (in the background, for example, by cron) [/quote] If so, then this is very similar to a bug, as for me, if there are procedures in the system that block records or completely tables, then other procedures must first clarify before the update whether the record or table is locked and after that carry out their work (while also blocking record or table) And here you exit so that there is a piece of code, you need to update something in it, the procedure was refused by the database, and then, well, okay, I’ll go further, transfer it to the status completed, I don’t care that the database gave a refusal, my task is to go to the status completed As far as I remember, you did not use the blocking principle anywhere, you wrote something like the code "who is the last one and slippers." Or am I not reasoning correctly and did not understand you correctly (it's just that now I have a bug hanging out the status of the story is one, in reality it's different and who will fix it is not clear to me)?

[quote] Kupriyan Vladislav Valerievich Baza.cn.ua / Integrator (FOP Kupriyan) wrote: Ustimenko Igor OneBox CTO wrote: 3. The table could be locked by another process (in the background, for example, by a cron). If so, then this is very similar to a bug, as for me, if there are procedures in the system that block the record or completely tables, then other procedures should first clarify before the update whether the record is locked or table and after that carry out its work (while also blocking the record or table) And here it comes out so there is a piece of code, you need to update something in it, the procedure was refused by the database, and then, well, okay, I’ll go further, translate into the status is completed, I don’t care that the database refused, my task is to go to the status completed As far as I remember, you didn’t use the blocking principle anywhere, you wrote something like the code “who is the last one and the slippers.” Or I’m not reasoning correctly and I didn’t understand you correctly (just I now have a bug hanging out the history status is one, in reality it’s different and who will fix it is not clear to me)? [/quote] Your theory is not correct. Vlad, I'm not ready to sit and teach you what MYSQL + LOCK table transactions are.

[quote] Ustimenko Igor OneBox CTO wrote: Kupriyan Vladislav ValerievichBaza.cn.ua / Integrator (FOP Kupriyan) wrote/a:Ustymenko Igor OneBox CTO wrote/a:3. The table could be locked by another process (in the background, for example, by a cron). If so, then this is very similar to a bug, as for me, if there are procedures in the system that block the record or completely tables, then other procedures should first clarify before the update whether the record is locked or table and after that carry out its work (while also blocking the record or table) And here it comes out so there is a piece of code, you need to update something in it, the procedure was refused by the database, and then, well, okay, I’ll go further, translate into the status is completed, I don’t care that the database refused, my task is to go to the status completed As far as I remember, you didn’t use the blocking principle anywhere, you wrote something like the code “who is the last one and the slippers.” Or I’m not reasoning correctly and I didn’t understand you correctly (just I now have a bug hanging out the status of history is one, in reality it is different and who will fix it is not clear to me)? Your theory is not correct. Vlad, I'm not ready to sit and teach you what MYSQL + LOCK table transactions are. [/quote] Igor, I’m also not ready to study, I don’t need it at the moment, I need the system to work stably, while things arise that frighten and defy any adequate logic (the base leaves lives its own life, the manager who presses the button in another comes out of reality ). While it’s not clear to me what the problem is, initially you said that the server, now the table is locked (as for me these are unrelated things, globally) Can you specifically tell me that you have a problem in this task with table locking, in order to solve this problem you need .... or that you have a bad server, little RAM (I will test the server and try to get this error again and then I will write to the hoster, so that I would test increase the parameters that are not enough, like the last time you said that you need to add RAM)?

Link what I wrote and answer your question Any transaction in the database locks the table, and the lock period depends on the power of the server, the more powerful it is, the faster it will perform the operation and unlock the table, and the chance to get to LOCK will be less. That's clearer?

[quote] Ustimenko Igor OneBox CTO wrote: Connect what I wrote and answer your question. Any transaction in the database locks the table, and the lock period depends on the power of the server, the more powerful it is, the faster it will perform the operation and unlock the table and the chance to get to LOCK will be less. That's clearer? [/quote] Yes, it is quite Why didn't the action check if the record was locked or not?

[quote] Kupriyan Vladislav Valerievich Baza.cn.ua / Integrator (FOP Kupriyan) wrote: Ustimenko Igor OneBox CTO wrote: Link what I wrote and answer your question Any transaction in the database locks the table, and the lock period depends on the power of the server, the more powerful it is, the faster it will perform the operation and unlock the table and the chance to get to LOCK will be less . So it's clearer? Yes, it's quite Why then the action did not check if the record was locked or not? [/quote] If you knock on the table before each request and check if it is LOCK or not , then the number of requests will increase by 1000 times .

[quote] Ustimenko Igor OneBox CTO wrote: Kupriyan Vladislav ValerievichBaza.cn.ua / Integrator (FOP Kupriyan) wrote: Ustimenko Igor OneBox CTO wrote: Connect what I wrote and answer your question the more powerful it is, the faster it will perform the operation and unlock the table, and the chance to hit LOCK will be less. So it's clearer? Yes, quite Why then the action did not check if the record was locked or not? If you knock on the table before each request and check whether it is LOCK or not, then the number of requests will increase by 1000 times. [/quote] I understand perfectly well that the lock check is a piece of code I participated in software development where a lot of attention was paid to this, and therefore I was surprised why it does not work in OneBox, I also understood that it reduces processing speed and is not critical, despite the fact that there is logging of actions (since this is not quite an accounting system, in accounting it is more critical) In general, I understand correctly that the fact that the product was not written off, but transferred to the status on which it should be written off is purely my problem (or business process or server settings)?

[quote] Kupriyan Vladislav Valerievich Baza.cn.ua / Integrator (FOP Kupriyan) wrote: Igor Ustimenko OneBox CTO wrote: Vladislav Kupriyan Baza.cn.ua / Integrator (FOP Kupriyan) wrote: Igor Ustimenko OneBox CTO wrote: Connect what I wrote and answer your question Any transaction in the database locks the table, and the lock period depends on the power of the server, the more powerful it is, the faster it will perform the operation and unlock the table, and the chance to get to LOCK will be less. So it’s clearer? Yes, it’s quite Why then the action didn’t check if the record was locked or not? If you knock on the table before each request and check whether it is LOCK or not, then the number of requests will grow 1000 times. I perfectly understand that the lock check is a piece of code I participated in software development where they paid a lot of attention to this and therefore I was surprised why it doesn’t work in OneBox, I also understood that it reduces processing speed and is not critical, despite the fact that there is logging of actions (since this is not quite an accounting system, in accounting this is more critical) In general, I understand correctly that the fact that the product was not written off, but transferred to the status on which it should be written off is purely my problem (or business process or server settings)? [/quote] Understand how you want - I'm not going to mess with you like a child, and others too I wrote to you in the 1st comment what has been done to solve the problem and what will happen the rest is purely your curiosity that takes up my time

In this task https://baza.cn.ua/admin/customorder/issue/23224/edit/ Not correctly displaying status https://prnt.sc/v1m3in Can you fix it?

no we don't do it for free

[quote] Ustimenko Igor OneBox CTO wrote: no we don't do it for free [/quote] Well, is it a bug that the system does not display correctly in history or is this normal?

[quote] Ustimenko Igor OneBox CTO wrote: [quote] Kupriyan Vladislav Valerievich Baza.cn.ua / Integrator (FOP Kupriyan) wrote: [quote] Ustimenko Igor OneBox CTO wrote: no we don't do it for free [/quote] Well, is it a bug that the system does not display correctly in history or is this normal? [/quote] you already answered why you can solve this issue yourself - by making a second transition to the stage [/quote] This "handbrake" comes out so that I can do this, I need to disable actions, etc. Plus, I'm not sure that this is such a problem in one process. Okay, I'll do it, but it seems to me that you should have done it, as a consequence of a bug