[Kde-pim] Possible bug in Akonadi::ChangeRecorder::replayNext()

[David Jarvie]

On Wednesday 16 November 2011 23:30:06 David Jarvie wrote:
> A ChangeReplay job seems to be getting stuck when the KAlarmResource starts up. Looking at the code in ChangeRecorder::replayNext(), it doesn't seem to handle the case highlighted below:
> 
> if ( !d->pendingNotifications.isEmpty() ) {
>   ...
>   if ( d->ensureDataAvailable( msg ) )
>     ...
>   else if ( !d->translateAndCompress( d->pipeline, msg ) ) {
>     ...
>   }
>   ///// *THIS CASE ISN'T HANDLED*
> } else {
>   // This is necessary when none of the notifications were accepted / processed above ...
> }
> 
> Shouldn't something happen in the unhandled case as well? KAlarmResource reaches that point and then seems to get stuck.

I've looked at this more, and there definitely seems to be something wrong with ChangeRecorder. Once the ChangeReplay job has been scheduled, the ResourceScheduler doesn't execute any more jobs for that resource. That is, it calls scheduleNext() for further jobs, but never calls executeNext() from then on. The last call to ChangeRecorder::replayNext() goes to the unhandled case (see above), and it never gets called again.

This can easily be reproduced, as follows:

1. Create a new KAlarm Calendar File resource in akonadiconsole, file /tmp/x.ics. Do not select read-only. Select Active Alarms.

2. Demonstrate configuration working correctly: Go to Configure Natively, and set the resource read-only. The resource's Collection -> Folder Properties -> Access Rights attribute changes, and its settings file (~/.kde/share/config/akonadi_kalarm_resourcexxrc) is updated to ReadOnly=true.

3. Run KAlarm, show the calendar list (View -> Show Calendars) and enable the resource by checking it in the list. This adds a KAlarmCollection attribute, value "1 0 0 0". This triggers the ChangeReply job to be scheduled, but it doesn't complete.

4. Demonstrate configuration not working: Go to Configure Natively, and clear the read-only setting. The Access Rights attribute does not update, but the settings file does. This is because although ResourceScheduler::scheduleCollectionTreeSync() is called, the CollectionTreeSync (which is responsible for updating the Access Rights attribute for SingleFileResource derived resources) never executes, because ChangeRecorder::replayNext() never does anything.


I hope somebody (Volker / Kevin?) can take a look at this to see why this is happening.

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm

_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/