feat(logging)!: add context variables to compression logs#2340
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughCompression scheduler and executor paths now bind job and task identifiers with ChangesCompression logging context
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
c92e29d to
8e7a960
Compare
| f"Compression task job_id={job_id} task_id={task_id} exceeded soft time limit." | ||
| ) | ||
| raise | ||
| with bound_contextvars(job_id=job_id, task_id=task_id): |
There was a problem hiding this comment.
bound_contextvars only attaches job_id and task_id while execution remains inside this
with block. The soft-timeout path is fine because it logs inside the block. For any other
exception from compression_entry_point—for example, configuration validation, run_clp, or a
database update—Python first exits the with block and removes these values. Celery then catches
the exception and emits its task-failure log without the CLP job and task IDs.
The sequence is:
- Bind
job_idandtask_id. compression_entry_pointraises an unexpected exception.- Execution leaves the
withblock, clearing the context. - Celery logs the failure without the correlation fields.
The Spider wrapper has equivalent behavior. _schedule_job has the same issue for exceptions not
caught locally: its bound scope ends before main logs Error in scheduling., so that log lacks
job_id.
Please either log a general exception inside each bound scope before re-raising it:
except Exception:
logger.exception("Compression task failed unexpectedly.")
raiseOr bind and clear the context through the worker/scheduler lifecycle so framework failure logging
still sees it.
Normal and explicitly handled paths are correct; this only affects unexpected failures, where
correlation is most valuable.
…devsot/clp into pr-compression-log-correlation
Description
Adds scoped log context to the compression scheduler and worker so compression logs include correlation fields such as
job_idandtask_id.This makes it easier to follow a compression job across scheduler logs, Celery worker logs, and subprocess log dumps.
Note
BREAKING CHANGE:
This PR changes the log text in compression scheduler and worker.
Checklist
breaking change.
Validation performed
Summary by CodeRabbit
Summary by CodeRabbit