[18.0][FIX] edi_core_oca: notify action completion based on exchange state#237
[18.0][FIX] edi_core_oca: notify action completion based on exchange state#237Ricardoalso wants to merge 1 commit into
Conversation
Ricardoalso
force-pushed
the
fix_notify_action_complete
branch
from
a04b068 to
01e9cef
Compare
|
This PR has the |
|
@Ricardoalso pls rebase |
Ricardoalso
force-pushed
the
fix_notify_action_complete
branch
from
01e9cef to
fc636a7
Compare
| } | ||
| ) | ||
| exchange_record.notify_action_complete("generate", message=message) | ||
| if exchange_record.edi_exchange_state == "output_pending": |
There was a problem hiding this comment.
I don't think this is correct. For instance, in this case, there won't be any notification for validate_ko.
A long time ago I refactored this part to always notify w/ notify_action_complete no matter what.
It doesn't not matter how it completes, it must always notify to trigger events or post a message somewhere.
What are you trying to solve in particular?
There was a problem hiding this comment.
For line 145, I agree with your feedback; my change is incorrect in restricting notification.
his PR targets the same underlying issue referenced in PR #240. The goal was to avoid calling notify_action_complete on an exchange_record with a dead cursor. I split the PRs to keep things explicit, but introducing a raise for OperationalError or IntegrityError ensures that if a cursor dies, the function flow is interrupted, and neither notification nor downstream hooks are triggered.
Without exception handling, the flow would continue, notifications would be sent, and hooks would run—which is exactly what we wanted to prevent when encountering these database errors. If you see other scenarios or states where this might not be sufficient, I’m open to suggestions!
There was a problem hiding this comment.
but if the errors are raised then you don't need this, am I wrong?
There was a problem hiding this comment.
If they are raised, there’s indeed no need, as notify_action_complete would not be reached.
| } | ||
| ) | ||
| exchange_record.notify_action_complete("send", message=message) | ||
| if exchange_record.edi_exchange_state in [ |
There was a problem hiding this comment.
@Ricardoalso based on your feedback above, if we merge #240 there's no reason to check the state here. Unless, we expect that we can still reach this line under some other circumstance.
If we expect that we need a comment to explain why.
And if we reach this state and we don't trigger the event it means something is fishy and I would at least return a proper message at the end so that at least ad job level we have a trace.
As an alternative we raise a UserError and let the job fail.
WDYT?
7 participants
CI failing because of FakeModelLoader; addressing it in #238
EDIT
Cherry-picked the FakeModelLoader commit in here in order to let the CI run, but I will rebase it as soon the FakeModelLoader PR gets merged #238