Update createjob result immediately and not after sending the mail.
ClosedPublic
Actions

Authored by • knauss on Jun 8 2015, 3:34 PM.

Details

Reviewers

Maniphest Tasks

Summary

If we create an exception from a events series, we also start an atomic
operation. createIncidence sends mails to attendees; the transistionJob
is finished before handleCreateJobResult2 is triggered.

With handleCreateJob we react on the correct end of createJob, so we
should also update the status of the job inside the atomicOperation.

Diff Detail

Branch

dev/invitations

Lint

No Lint Coverage

Unit

No Test Coverage

Event Timeline

remove kWarning

The change is fine I guess, but the description doesn't make any sense. There is no handleCreateJob2 or a transitionJob, so I don't really know what this patch is about.

If you're confident this fixes something then go ahead and write a better commit message please.

This revision is now accepted and ready to land.Jun 8 2015, 5:46 PM

If we create an exception from a events series, we also start an atomic
operation and createIncidence will send mails to attendees.
The mail triggers the finish of Akonadi::TransactionSequence
(handleTransactionJobResult) of the atomic operation
before handleCreateJobResult2 is executed. That made the job not been
marked as finished, when the handleTransactionJobResult was called. And
made handleTransactionJobResult to fail, because it checks if all
subjobs are executed:

Q_ASSERT(!operation->pendingJobs());

If we update the job result directly in the result function
(handleCreateJob) of the createJob and not after sending the mail, than the
status is uptodate when handleTransactionJobResult is called. All other
types of handlers (modify and delete) do it the same way.