Will commit in a few days, if noone objects. So it has some weeks for testing outside my system before the next KF release.

@kossebau
After this change we get the

Tried to unregister a kio job that hasn't been registered.

warning with a KCompositeJob in Ark (batchextract.cpp).

The job is now automatically unregistered and the unregisterJob(this) call in the job destructor is causing this warning.
Are KCompositeJobs still supposed to unregister themselves?

In D3977#155721, @elvisangelaccio wrote:

@kossebau
After this change we get the

   Tried to unregister a kio job that hasn't been registered.
 
warning with a `KCompositeJob` in Ark (batchextract.cpp).

The job is now automatically unregistered and the unregisterJob(this) call in the job destructor is causing this warning.
Are KCompositeJobs still supposed to unregister themselves?

KJob related knowledge sadly completely swapped out of my brain, would need to investigate myself. No idea if there should be done anything special for KCompositeJobs.

On a quick look the automatic unregistering based on the finished signal seems to make sense for any KJob subclass. Perhaps the change in this commit conflicts with some older code in Ark to work around the old behaviour and which does some additional manual unregistration? Or perhaps some slot in accidentally invoked 2x so the unregistration happens more than once, with the second try than failing? Wild guesses is all I have to offer, sorry. I cannot remember anything questionable about this patch, so no pointers into it, instead my initial reaction would be to look at the consumer side.

In D3977#155762, @kossebau wrote:

On a quick look the automatic unregistering based on the finished signal seems to make sense for any KJob subclass. Perhaps the change in this commit conflicts with some older code in Ark to work around the old behaviour and which does some additional manual unregistration? Or perhaps some slot in accidentally invoked 2x so the unregistration happens more than once, with the second try than failing? Wild guesses is all I have to offer, sorry. I cannot remember anything questionable about this patch, so no pointers into it, instead my initial reaction would be to look at the consumer side.

Yes Ark has a manual unregistration, which I can easily fix.
From what I can see, after this change any job registered with

KIO::getJobTracker()->registerJob(job);

no longer needs to be manually unregistered with

KIO::getJobTracker()->unregisterJob(job);

This is a minor thing, but should probably be documented somewhere.

In D3977#155973, @elvisangelaccio wrote:

From what I can see, after this change any job registered with

KIO::getJobTracker()->registerJob(job);

no longer needs to be manually unregistered with

KIO::getJobTracker()->unregisterJob(job);

Looking at the history, KJobTrackerInterface::registerJob(KJob *job)has connected the job's finished(KJob*) signal to the tracker's unregisterJob(KJob*) since ages, 2008 and possibly longer (cmp. https://phabricator.kde.org/R446:7308fa7e6b756f5c6fe1b8adbcc6095e3bb5b995)

And this commit here now uncovered that somehow for Ark as well.

This is a minor thing, but should probably be documented somewhere.

Agreed, by just looking at the API (dox) one would assume one had to possibly also unregister manually. You proposed it -> you do it? :)