Skip to content

[18.0][FIX] edi_core_oca: notify action completion based on exchange state #237

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Ricardoalso wants to merge 1 commit into
base: 18.0
Choose a base branch
from
+11 −4
Open

[18.0][FIX] edi_core_oca: notify action completion based on exchange state #237

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions edi_core_oca/models/edi_backend.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,8 @@ def exchange_generate(self, exchange_record, store=True, force=False, **kw):
"exchange_error_traceback": traceback,
}
)
exchange_record.notify_action_complete("generate", message=message)
if exchange_record.edi_exchange_state == "output_pending":
Copy link
Copy Markdown
Contributor

@simahawk simahawk Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

@Ricardoalso Ricardoalso Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Copy Markdown
Contributor

@simahawk simahawk Feb 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but if the errors are raised then you don't need this, am I wrong?

Copy link
Copy Markdown
Contributor Author

@Ricardoalso Ricardoalso Feb 26, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If they are raised, there’s indeed no need, as notify_action_complete would not be reached.

exchange_record.notify_action_complete("generate", message=message)
return message

# TODO: unify to all other checkes that return something
Expand Down Expand Up @@ -258,7 +259,11 @@ def exchange_send(self, exchange_record):
"exchanged_on": fields.Datetime.now(),
}
)
exchange_record.notify_action_complete("send", message=message)
if exchange_record.edi_exchange_state in [
Copy link
Copy Markdown
Contributor

@simahawk simahawk May 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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?

"output_sent",
"output_sent_and_processed",
]:
exchange_record.notify_action_complete("send", message=message)
return res

def _swallable_exceptions(self):
Expand Down Expand Up @@ -466,7 +471,8 @@ def exchange_process(self, exchange_record):
exchange_record._notify_error("process_ko")
elif state == "input_processed":
exchange_record._notify_done()
exchange_record.notify_action_complete("process", message=message)
if exchange_record.edi_exchange_state == "input_processed":
exchange_record.notify_action_complete("process", message=message)
return res

def _exchange_process(self, exchange_record):
Expand Down Expand Up @@ -522,7 +528,8 @@ def exchange_receive(self, exchange_record):
"exchanged_on": fields.Datetime.now(),
}
)
exchange_record.notify_action_complete("receive", message=message)
if exchange_record.edi_exchange_state == "input_processed":
exchange_record.notify_action_complete("receive", message=message)
return res

def _exchange_receive_check(self, exchange_record):
Expand Down