If the worker running a job was restarted mid-run — a deploy, a busy spike — the job was marked failed and you had to start it again by hand. Now it resumes on its own: the run is re-queued automatically, and because a re-run only copies what's still missing, it picks up where it left off rather than starting over. A job that repeatedly loses its worker still stops after a few attempts, so a genuinely broken job can't loop forever.

Two related fixes:

• •A job copying many small files could open more connections than a server was willing to accept and start failing files. Jobs now sense a server's real limit and ease off instead of failing — the run just takes a little longer.
• •Busy migrations were occasionally cut short by an over-eager internal health check that mistook "working hard" for "stuck". That's been given the headroom a long transfer needs.