Open doofmars opened 1 year ago
Did you try just to Unsubscribe / Subscribe? It seems, at least for now, to do the trick for me. I'm running 0.9.2 too but on SQLite and issue was with TB 102.9.0.
Edit! I can confirm, after doing the unsubscribe / subscribe on all my running TB, it works as intended now.
Yes I did. See my steps to reproduce. I setup a fresh local baikal + portable thunderbird. Loaded in my existing calendar data and connected the two. Any unsubscribe and resubscribe the issue was still there with syncing any new created items from outside.
The only solution was to manually reset of the calendarchanges
table and resetting the synctoken
.
If I understand the database this data is not really required as the actual calendar data is stored in a different table.
Since this change everything works again.
I found a working workaround, yet I'm still submitting this report. In case someone else has the same issue or if there is some simple fix that can be implemented this can be used as base for discussion.
Baikal version: 0.9.2 using MySQL database PHP 8.1
Expected behaviour: When I perform a sync on Thunderbird (v102) I expect new entries to be synced and show up in the calendar. The entries are exist in the database and have been created since the last sync.
Current behaviour: On clicking sync in Thunderbird a request with a sync ID is send to Baikal but the response does not contain any calendar entries to be fetched.
DAVx5 seems to access Baikal differently than Thunderbird. Thunderbird can access Baikal, but only "one way"
Workaround:
After digging around in the database I figured out that the
synctoken
values might be not in sync with the calendar changes. Purging thecalendarchanges
table of all entries and setting thesynctoken
in thecalendars
table to 1 for each calendar entry did solve this issue. Afterwards the calendar must be resubscribed in order to get the updatedsynctoken
.On the old table before the purge the sync token was at 500 (
SELECT synctoken FROM
calendarsWHERE id = 2
) but the highest synctoken for this calendarchanges was 943 (SELECT synctoken FROM
calendarchangesWHERE calendarid = 2 order by synctoken desc limit 1
)Steps to reproduce: On a fresh Baikal version this seems reproduce the issue:
synctoken
in thecalendars
table to a high starting value (e.g. 100)synctoken
in thecalendars
table to a lower value (e.g. 50)synctoken
in the requestI do not know what exactly caused this issue I started noticing this only after the recent update of Baikal from 0.7.1 to 0.9.2