Tryton - Issues

 

Issue8342

Title Trigger should be asynchronous
Priority feature Status resolved
Superseder Nosy List ced, pokoli, reviewbot, roundup-bot
Type performance Components notification_email, trytond
Assigned To ced Keywords review
Reviews 280971002
View: 280971002

Created on 2019-05-10.11:50:24 by ced, last changed by roundup-bot.

Messages
New changeset fb4eaea3c2df by Cédric Krier in branch 'default':
Cast CurrentTimestamp into timestamp to remove timezone
https://hg.tryton.org/tryton-env/rev/fb4eaea3c2df

New changeset fdd5f29247aa by Cédric Krier in branch 'default':
Remove unused time import
https://hg.tryton.org/tryton-env/rev/fdd5f29247aa
New changeset 17f3841e931b by Cédric Krier in branch 'default':
Cast CurrentTimestamp into timestamp to remove timezone
https://hg.tryton.org/trytond/rev/17f3841e931b

New changeset 9a93b7d87ca2 by Cédric Krier in branch 'default':
Remove unused time import
https://hg.tryton.org/trytond/rev/9a93b7d87ca2
New changeset bdbbdc0ba62b by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/tryton-env/rev/bdbbdc0ba62b
New changeset c9a5103e09bd by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/trytond/rev/c9a5103e09bd
New changeset 7a2b34196f4f by Cédric Krier in branch 'default':
Run trigger in the queue
https://hg.tryton.org/modules/notification_email/rev/7a2b34196f4f
review280971002 updated at https://codereview.tryton.org/280971002/#ps289501003
review280971002 updated at https://codereview.tryton.org/280971002/#ps278731002
msg56153 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2020-03-09.12:39:39
I found that it should also be unique be transaction.
Take for example this scenario:

The setup is based on a draft sale with a trigger to quotation.
During the processing, the sale is written multiple times: set a carrier, compute cost etc. For each of this write calls, the trigger will be queued for the same record because the sale is still in draft (eval is False). Finally the sale is written to quotation and a last trigger is queued.
So at the end of the transaction the same trigger record is called for each time the sale was written until the state change.

So for me, we should keep track of the trigger called during the transaction to call it only once.
review280971002 updated at https://codereview.tryton.org/280971002/#ps266881002
review280971002 updated at https://codereview.tryton.org/280971002/#ps297111002
msg49708 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-05-13.08:53:45
After reading your use case the new behaviour makes sense for me.
msg49705 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.19:28:41
I think it is better because how the modularity is managed in Tryton.
My use case which showed the bad behavior is that I got a trigger on sale quotation to send an email. But also I also get the module sale_promotion which applies the promotion on quotation but after the sale has been written to 'quoted'.
So the email is sent with the data before the apply of promotions.

For me, it is clear that trigger should be executed at the end of the transaction. And in your case you should just include the 'paid' state in the trigger condition.
msg49693 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.13:48:12
Yes you understood correctly. This will be a change in the behavior but for the best.
msg49682 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2019-05-10.12:02:10
What do you mean by the evaluation should be done at queue job?

We currently have a notification_email when the invoice is posted which filters that the state is posted. Currently when posting an invoice with zero amount the trigger is executed because the invoice is first moved to posted state and then moved to paid. 

But IIUC, if we evaluate the trigge at queue job, the invoice state will be paid directly and the trigger will not be executed, which for me is not the expected behaviour.

Did I understand it correctly?
msg49681 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2019-05-10.11:50:23
The existing code should not rely on trigger being executed right after create or write. So we could use the queue to post those actions.
But the evaluation should be done at the queue job in case the record state changed.
Also we could replace the action_model and action_function for a selection like in Cron.
Finally it could be also the occasion to implement issue4278.
History
Date User Action Args
2020-03-28 23:38:13roundup-botsetmessages: + msg56766
2020-03-28 23:37:59roundup-botsetmessages: + msg56765
2020-03-28 17:16:19roundup-botsetmessages: + msg56761
2020-03-28 17:16:14roundup-botsetmessages: + msg56760
2020-03-28 17:16:07roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg56759
2020-03-17 23:25:23reviewbotsetmessages: + msg56354
2020-03-09 13:04:42reviewbotsetmessages: + msg56154
2020-03-09 12:39:40cedsetmessages: + msg56153
2020-02-27 14:41:57reviewbotsetmessages: + msg55625
2020-02-27 13:16:57reviewbotsetnosy: + reviewbot
messages: + msg55621

Showing 10 items. Show all history (warning: this could be VERY long)