-
David Faure authored
Summary: - it turns out that the whole job gets terminated - after changing FakeSession to delay reconnect like Session, the unittest actually makes more sense (no more comment about signal not received because emitted from the constructor) - call socketDisconnected like Session ends up doing The main point was to debug a crash I was having in TransactionSequence when killing subjobs in rollback(). The take away is that disconnecting from slotResult is a horrible idea, it means mCurrentSubJob stays dangling and later lostConnection() crashes. Disconnecting is currently only done for non-running jobs, but too much code sharing brought me into that bug :) Reviewers: dvratil Reviewed By: dvratil Subscribers: kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D19742
a9be84f5