Server: ReminderService::parseCalendarData() must be of the type string

[enoch85]

Steps to reproduce

No idea. I think it's when sending calendar invitations from the Web calendar.

Expected behaviour

No errors

Actual behaviour

See nextcloud.log

Calendar app

Calendar app version: (see apps admin page, e.g. 2.0.1)
1.7.1

CalDAV-clients used: (Thunderbird Lightning, DAVx5, Evolution, macOS Calendar, etc)
DAVx5

Client configuration

Browser: (e.g. Firefox 48)
Firefox

Operating system: (e.g. Arch Linux)
Ubuntu 18.04

Server configuration

Operating system: (e.g. Debian 8)
Ubuntu 18.04

Web server: (e.g. Apache, Nginx,...)
Apache 2.4

Database: (e.g. MariaDB, SQLite or PostgreSQL)
PosgreSQL 10

PHP version: (e.g. 7.0.3)
7.2

Nextcloud Version: (see admin page, e.g. 17.0.2)
17.0.1

Updated from an older installed version or fresh install:
Updated

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your instance's installation folder

Nextcloud configuration:

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your instance's installation folder

or

Insert your config.php content here
Make sure to remove all sensitive content such as passwords. (e.g. database password, passwordsalt, secret, smtp password, …)

Logs

Web server error log (e.g. /var/log/apache)

Insert your webserver log here

Log file (data/nextcloud.log)

[cron] Error: TypeError: Argument 1 passed to OCA\DAV\CalDAV\Reminder\ReminderService::parseCalendarData() must be of the type string, resource given, called in /var/www/nextcloud/apps/dav/lib/CalDAV/Reminder/ReminderService.php on line 110 at <<closure>>

0. /var/www/nextcloud/apps/dav/lib/CalDAV/Reminder/ReminderService.php line 110
   OCA\DAV\CalDAV\Reminder\ReminderService->parseCalendarData(null)
1. /var/www/nextcloud/apps/dav/lib/BackgroundJob/EventReminderJob.php line 62
   OCA\DAV\CalDAV\Reminder\ReminderService->processReminders()
2. /var/www/nextcloud/lib/private/BackgroundJob/Job.php line 61
   OCA\DAV\BackgroundJob\EventReminderJob->run(null)
3. /var/www/nextcloud/lib/private/BackgroundJob/TimedJob.php line 55
   OC\BackgroundJob\Job->execute(OC\BackgroundJob\JobList {}, OC\Log {})
4. /var/www/nextcloud/cron.php line 124
   OC\BackgroundJob\TimedJob->execute(OC\BackgroundJob\JobList {}, OC\Log {})

at 2019-11-14T12:00:27+01:00

[core] Error: OCP\AppFramework\QueryException: Could not resolve PageController! Class PageController does not exist at <<closure>>

0. /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php line 114
   OC\AppFramework\Utility\SimpleContainer->resolve("PageController")
1. /var/www/nextcloud/lib/private/ServerContainer.php line 145
   OC\AppFramework\Utility\SimpleContainer->query("PageController", true)
2. /var/www/nextcloud/lib/private/AppFramework/DependencyInjection/DIContainer.php line 388
   OC\ServerContainer->query("PageController", true)
3. /var/www/nextcloud/apps/phonetrack/lib/Cron/AutoExport.php line 24
   OC\AppFramework\DependencyInjection\DIContainer->query("PageController")
4. /var/www/nextcloud/lib/private/BackgroundJob/Job.php line 61
   OCA\PhoneTrack\Cron\AutoExport->run(null)
5. /var/www/nextcloud/lib/private/BackgroundJob/TimedJob.php line 55
   OC\BackgroundJob\Job->execute(OC\BackgroundJob\JobList {}, OC\Log {})
6. /var/www/nextcloud/cron.php line 124
   OC\BackgroundJob\TimedJob->execute(OC\BackgroundJob\JobList {}, OC\Log {})

at 2019-11-12T21:15:27+01:00

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log
c) ...

[georgehrke]

@enoch85 As the big note on top of the issue template states: CalDAV issues belong in the server :)

[georgehrke]

@enoch85 can you please check the database. I suspect that there is some row in oc_calendarobjects where calendardata is not a string.

[cvandesande]

Have this exact issue, using PostgreSQL as DB. Not sure how to check the datatype of a column though. Can you suggest a command?

[cvandesande]

Here's the output of "\d oc_calendarobjects"

nextcloud=# \d oc_calendarobjects
                                        Table "public.oc_calendarobjects"
     Column     |          Type          | Collation | Nullable |                    Default                     
----------------+------------------------+-----------+----------+------------------------------------------------
 id             | bigint                 |           | not null | nextval('oc_calendarobjects_id_seq'::regclass)
 calendardata   | bytea                  |           |          | 
 uri            | character varying(255) |           |          | NULL::character varying
 calendarid     | bigint                 |           | not null | 
 lastmodified   | integer                |           |          | 
 etag           | character varying(32)  |           |          | NULL::character varying
 size           | bigint                 |           | not null | 
 componenttype  | character varying(8)   |           |          | NULL::character varying
 firstoccurence | bigint                 |           |          | 
 lastoccurence  | bigint                 |           |          | 
 uid            | character varying(255) |           |          | NULL::character varying
 classification | integer                |           |          | 0
 calendartype   | integer                |           | not null | 0
Indexes:
    "oc_calendarobjects_pkey" PRIMARY KEY, btree (id)
    "calobjects_index" UNIQUE, btree (calendarid, calendartype, uri)
Publications:
    "nextcloudpub"

nextcloud=#

[enoch85]

I suspect that there is some row in oc_calendarobjects where calendardata is not a string.

@georgehrke I'm not exactly sure what you mean by that, but here are my output from the command above:

nextcloud_db=# \d oc_calendarobjects
                                        Table "public.oc_calendarobjects"
     Column     |          Type          | Collation | Nullable |                    Default                     
----------------+------------------------+-----------+----------+------------------------------------------------
 id             | bigint                 |           | not null | nextval('oc_calendarobjects_id_seq'::regclass)
 calendardata   | bytea                  |           |          | 
 uri            | character varying(255) |           |          | NULL::character varying
 calendarid     | bigint                 |           | not null | 
 lastmodified   | integer                |           |          | 
 etag           | character varying(32)  |           |          | NULL::character varying
 size           | bigint                 |           | not null | 
 componenttype  | character varying(8)   |           |          | NULL::character varying
 firstoccurence | bigint                 |           |          | 
 lastoccurence  | bigint                 |           |          | 
 uid            | character varying(255) |           |          | NULL::character varying
 classification | integer                |           |          | 0
 calendartype   | integer                |           | not null | 0
Indexes:
    "oc_calendarobjects_pkey" PRIMARY KEY, btree (id)
    "calobjects_index" UNIQUE, btree (calendarid, calendartype, uri)

[georgehrke]

My question was not about the database structure itself, but whether there is a row inside the table that where calendar data is empty.

[enoch85]

My question was not about the database structure itself, but whether there is a row inside the table that where calendar data is empty.

How would you get that information, do you have any command in your backpocket? :)

[cvandesande]

This is what I came up with:

Expanded display is on.
nextcloud=# select * from oc_calendarobjects where calendardata is null;
(0 rows)

nextcloud=#

[ghost]

I’m experiencing the same issue and I am also using Postgresql as DB. This didn’t happen in Nextcloud 16.

I am not sending calendar invites. It started happening after I added a new calendar entry.

The entry was successfully saved (and new ones are too), but I keep getting this error in the logs every few hours from cron. I am calling cron.php via crontab.

[georgehrke]

@cvandesande Can you check for any rows where calendar data is an empty string?

[cvandesande]

0 rows :(

nextcloud=# select * from oc_calendarobjects where calendardata='';
 id | calendardata | uri | calendarid | lastmodified | etag | size | componenttype | firstoccurence | lastoccurence | uid | classification | calendartype 
----+--------------+-----+------------+--------------+------+------+---------------+----------------+---------------+-----+----------------+--------------
(0 rows)

[georgehrke]

Can you please check if this PR fixes the problem for you?
https://github.com/nextcloud/server/pull/18115

Thx!

[cvandesande]

I've applied the changes, but the error seems to occur only every 12 hours, (1:30 and 13:30GMT daily) so I will try to follow up tomorrow

[ghost]

Any news? I’m currently travelling so I cannot try the PR myself

[cvandesande]

No more errors since applying the patch. Think we're good now!

On November 28, 2019 10:57:10 AM UTC, ichi_i [e-mail] wrote:

Any news? I’m currently travelling so I cannot try the PR myself>
>
-- >
You are receiving this because you were mentioned.>
Reply to this email directly or view it on GitHub:>
https://github.com/nextcloud/server/issues/17951#issuecomment-559446529

[oreinert]

I have also tested the patch, and for me it also removed the errors that occur every 12h.

[cvandesande]

Just for completeness, it's been a full week since the error occurred, no reoccurrence of the error since applying the patch.

[cvandesande]

Updating to 17.0.2 has undone the patch. Any idea when this fix will get merged?

[enoch85]

Updating to 17.0.2 has undone the patch. Any idea when this fix will get merged?

Seems like it only will happen in Nextcloud 18. But I might be wrong: https://github.com/nextcloud/server/pull/18115

[brot]

Updating to 17.0.2 has undone the patch. Any idea when this fix will get merged?

Seems like it only will happen in Nextcloud 18. But I might be wrong: #18115

No, I'm running Nextcloud 17.0.2 and I'm also affected by this problem

[cron] Error: TypeError: Argument 1 passed to OCA\DAV\CalDAV\Reminder\ReminderService::parseCalendarData() must be of the type string, resource given, called in /var/www/html/apps/dav/lib/CalDAV/Reminder/ReminderService.php on line 110 at <<closure>>

0. /var/www/html/apps/dav/lib/CalDAV/Reminder/ReminderService.php line 110
   OCA\DAV\CalDAV\Reminder\ReminderService->parseCalendarData(null)
1. /var/www/html/apps/dav/lib/BackgroundJob/EventReminderJob.php line 62
   OCA\DAV\CalDAV\Reminder\ReminderService->processReminders()
2. /var/www/html/lib/private/BackgroundJob/Job.php line 61
   OCA\DAV\BackgroundJob\EventReminderJob->run(null)
3. /var/www/html/lib/private/BackgroundJob/TimedJob.php line 55
   OC\BackgroundJob\Job->execute(OC\BackgroundJob\JobList {}, OC\Log {})
4. /var/www/html/cron.php line 124
   OC\BackgroundJob\TimedJob->execute(OC\BackgroundJob\JobList {}, OC\Log {})

at 2020-01-13T14:35:01+00:00

[georgehrke]

The bugfix was not back ported to Nextcloud 17 yet. Let me take care of that.

[nousernameavailableanymore]

I have the exact same issue on NC 19.0.2 with PHP 7.4 installed on Ubuntu 20.04.
select * from oc_calendarobjects where calendardata is null; returns 0 rows.

I imported a couple of Google Calendars when I started with NC and have the issue that no notifications are sent via mail at all.
When exporting the calendars from NC it looks like the old Google Calendars may contain some characters that NC might be tripping about.

Any ideas on how to further troubleshoot that would be appreciated.

[nousernameavailableanymore]

I have now even validated all my calendars and removed all subscribed calendars that showed errors.
So all my current calendars pass the validator on icalendar.org without errors, however the issue still remains.

[tommasig]

I had the same issue on NC 20.0.2, and I solved it by manually deleting the rows in calendar_reminders that pointed to non-existent rows in calendars.

This is the query that NC executes and that you should check for calendardata NULLs:

SELECT cr.*, co.calendardata, c.displayname, c.principaluri
FROM oc_calendar_reminders AS cr
LEFT JOIN oc_calendarobjects AS co ON cr.object_id = co.id
LEFT JOIN oc_calendars AS c ON cr.calendar_id = c.id
WHERE co.calendardata IS NULL

edit: added the WHERE clause and indentation

[nousernameavailableanymore]

@tommasig
I ran the select query and it came up with _4 results_.

I then tried to delete those by running:

delete from oc_calendar_reminders
where exists(
SELECT cr.*, co.calendardata, c.displayname, c.principaluri
FROM oc_calendar_reminders AS cr
LEFT JOIN oc_calendarobjects AS co ON cr.object_id = co.id
LEFT JOIN oc_calendars AS c ON cr.calendar_id = c.id
WHERE co.calendardata IS NULL);

However, this showed me that _7 lines_ were affected.
Running your initial select query again, showed that 0 results were now found and the error also does not appear in the log anymore.
So the issue was resolved by that.

Any idea, why the delete query showed 7 affected lines?
Could I have broken something with that?
What would have been the correct query to delete the results from your select query?

[tommasig]

@nousernameavailableanymore

Sorry for the delay in the answer.
I'm not an expert in mysql syntax, so I can't really say why it deleted 7 rows. If I had to guess it would be that the delete captured the rows in the other tables involved. Since the calendardata is null, then all the calendarobject would be null so it couldn't be the one deleted. This leaves only the rows in calendars.
In my case those calendars were left behind by some db cleanup I had done manually so, even if they were deleted, it wouldn't matter. I hope it's the same in your case. You should check if all your calendars are still there.

I think a more accurate delete query would have been something like:

DELETE cr
FROM oc_calendar_reminders AS cr
LEFT JOIN oc_calendarobjects AS co ON cr.object_id = co.id
LEFT JOIN oc_calendars AS c ON cr.calendar_id = c.id
WHERE co.calendardata IS NULL

I haven't tried it though. Since I had to delete only 2 rows and I was managing the db using phpMyAdmin I just used the web interface to do it for me.