Skip to content
Open
Changes from all commits
Commits
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
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
Contributor

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
Contributor Author

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
Contributor

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
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.

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 [
"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