3.0.0b1 #1285
ewjoachim
announced in
Announcements
3.0.0b1
#1285
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What's Changed
Breaking changes
A long, complex, necessary and highly appreciated work from @onlyann who has been quite active this year: rewriting most of the main job processing loop of the Procrastinate Worker (#1114) as discussed in #933. It was followed by quite a few improvements we wanted to make for a long time and took the opportunity of a breaking release to do, as described below.
Changes include:
X.Y.Z
before upgrading the code toX.Y.Z
with complex procedures around minor/major versions. The new way is that migrations are noted aspre
orpost
, you apply thepre
migrations before deploying the accompagnying new version of Procrastinate, and you apply thepost
migrations after deploying the said code. If you are several versions late, you'll have to repeat these for every intermediate release that comes with migrations. See the Migration documentation.asyncio
'scancel
method, which can be handled gracefully by users using shielding, as explained in the Cancel documentation. Synchronous jobs will not be cancelled, butjob_context.should_abort()
will returnTrue
so that you can handle the abortion request in your code.shutdown_graceful_timeout
. During shutdown, jobs (both synchronous and asynchronous) get an abort request as described in the previous bullet point. See all details in the Shutdown documentation.ABORTING
). It's now an independent field (Job.abort_requested
). This has implications if you introspect job states, such as with the Job objects or via the Django integration.timeout
worker option was renamed tofetch_job_polling_interval
to better reflect its purpose. It's accompanied by a new settingabort_job_polling_interval
. Both regulate how often the worker contacts the database to request new jobs or cancellation requests, in case they don't receive notifications from theLISTEN/NOTIFY
mechanism. This is explained in the Polling documentation. Note that the work from @onlyann led to workers making significantly less SQL queries, especially for workers with high concurrency settings.JobContext
object that your tasks receive if thetask
decorator was passed withpass_context=True
:job_context.job_result
was removed. The only relevant information it contained was the start timestamp, which is now accessible viajob_context.start_timestamp
app
andjob
had static typing, mentioning that those attributes could beNone
while they actually were always set. They are now properly typed.job_context.should_abort_async()
was removed. Knowing whether the job should abort or not, is not doing I/Os anymore, so both sync and async code can now usejob_context.should_abort()
.job_context.abort_reason
tells you whether a job is being aborted because the user requested an abortion, or because the worker is stopping.job_context.task
attribute is now a read-only property. Not that it wasn't a good idea to modify it before, but in the very surprising case that one would do, that's now not possible anymore.builtin_tasks.remove_old_jobs()
,remove_error
was renamed toremove_failed
for consistency. Similarly, inJobManager.delete_old_jobs()
,include_error
was renamedinclude_failed
.Bug Fixes
Related PRs:
Miscellaneous
Documentation
Dependencies
Kudos
MVPs
New contributors for this release
Feedback
We'd love for you to share your thoughts about this release to us:
Full Changelog: 2.14.0...3.0.0b1
This discussion was created from the release 3.0.0b1.
Beta Was this translation helpful? Give feedback.
All reactions