-
Notifications
You must be signed in to change notification settings - Fork 29
[IMP] base_bg: Improvement in jobs run policy #337
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.
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Este PR mejora la política de ejecución de jobs en background implementando un mecanismo de bloqueo optimista con SELECT FOR UPDATE SKIP LOCKED para permitir que múltiples crons procesen jobs concurrentemente sin conflictos.
Changes:
- Introduce el método
_try_lock_job()que usa bloqueo a nivel de base de datos para adquirir jobs de forma segura - Refactoriza
_cron_run_enqueued_jobs()para procesar un solo job por ejecución en lugar de múltiples, eliminando la lógica de distribución manual basada en módulo de IDs - Implementa auto-disparo recursivo de crons cuando quedan jobs pendientes
6ae0a5a to
aa391d2
Compare
aa391d2 to
3429cf6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 8 comments.
Comments suppressed due to low confidence (3)
base_bg/tests/test_bg_job.py:199
- Este test está roto porque la nueva firma de
bg_enqueuerequiererecordscomo primer argumento posicional, pero aquí se pasa"dummy_priority_method"(el método) como primer argumento. Debe agregarse un recordset antes del método:self.base_bg_model.bg_enqueue(self.env["base.bg"], "dummy_priority_method", ...).
def test_bg_enqueue_applies_custom_priority(self):
"""bg_enqueue must propagate the provided priority into bg.job."""
job_name = f"Priority Test Job {uuid4().hex}"
with patch.object(BaseBg, "_trigger_crons"):
self.base_bg_model.bg_enqueue(
"dummy_priority_method",
name=job_name,
priority=3,
)
base_bg/tests/test_bg_job.py:218
- Igual que el comentario anterior, este test está roto porque falta el argumento
recordscomo primer parámetro debg_enqueue. Debe agregarse un recordset válido.
def test_bg_enqueue_filters_unserializable_context_entries(self):
"""Only JSON-safe context keys should be stored in bg.job."""
job_name = f"Context Test Job {uuid4().hex}"
partner = self.env["res.partner"].create({"name": "Context Partner"})
base_bg_ctx = self.base_bg_model.with_context(
serializable_flag="ok",
unserializable_partner=partner,
unserializable_env=self.env,
)
with patch.object(BaseBg, "_trigger_crons"):
base_bg_ctx.bg_enqueue(
"dummy_context_method",
name=job_name,
)
base_bg/models/base_bg.py:21
- El cambio de firma de
bg_enqueue(self, method, *args, **kwargs)abg_enqueue(self, records, method, threshold, *args, **kwargs)es un cambio que rompe la API pública. La forma en que estaba diseñada antes,bg_enqueueusabaselfcomo los registros a procesar. Ahora requiere pasarrecordsexplícitamente, lo que rompe todo código existente que llame a este método. Se debería mantener retrocompatibilidad detectando si el primer argumento es un string (método) o un recordset, o documentar claramente este breaking change en las notas de migración.
def bg_enqueue(self, records, method: str, threshold: int | None = None, *args, **kwargs) -> tuple[dict, "BgJob"]:
6545ffe to
2e4fe0b
Compare
41ceffe to
462c3d7
Compare
5916e9e to
b27b65e
Compare
- Improvement in jobs run policy - Add batch job processing with threshold-based record splitting
b27b65e to
14d17e1
Compare
|
Seguimos en PR #347 v18 |

No description provided.