mirror of
https://github.com/odoo/runbot.git
synced 2025-03-15 23:45:44 +07:00
2fea318830
As far as I can tell they are properly handled: - In `handle_status` we let the http layer retry the query, which pretty much always succeeds. - In `Commit.notify`, we rollback the application of the current commit, meaning it'll be processed by the next run of the cron, which also seems to succeed every time (that is going through the log I pretty much never notice the same commit being serialization failure'd twice in a row). Which we can trigger for faster action, this last item is not entirely necessary as statuses should generally come in fast and especially if we have concurrency errors, but it can't hurt. This means the only genuine issue is... sql_db logging a "bad query" every time there's a serialization failure. In `handle_status`, just suppress the message outright, if there's an error other than serialization the http / dispatch layer should catch and log it. In `Commit._notify` things are slightly more difficult as the execute is implicit (`flush` -> `_write` -> `execute`) so we can't pass the flag by parameter. One option would be to set and unset `_default_log_exception`, but it would either be a bit dodgy or it would require using a context manager and increasing the indentation level (or using a custom context manager). Instead just `mute_logger` the fucking thing. It's a bit brutish and mostly used in tests, but not just, and feels like the least bad option here... Closes #805 |
||
|---|---|---|
| .. | ||
| backport | ||
| crons | ||
| project_freeze | ||
| staging_cancel | ||
| __init__.py | ||
| batch.py | ||
| commands.py | ||
| events_sources.py | ||
| ir_actions.py | ||
| ir_ui_view.py | ||
| patcher.py | ||
| project.py | ||
| pull_requests.py | ||
| res_partner.py | ||
| stagings_create.py | ||
| utils.py | ||