Meetings setup in Office and sent to external people don't actually send invite to people #1

Open
opened 2026-06-23 10:30:47 -04:00 by tristan · 2 comments
Owner

I can add external emails to a meeting invite, but the invite never actually sends.

I can add external emails to a meeting invite, but the invite never actually sends.
Owner

Fixed and live — please verify

Root cause was not a permissions or external-recipient problem, and it was worse than the title
suggests: since 2026-06-29, saving an event with any attendee (internal or external) failed for
every user with "Failed to save event".

The 2026-06-29 attempt to fix this issue patched core Nextcloud
(apps/dav/lib/CalDAV/Schedule/IMipPlugin.php) to send invites from the organizer's own mail account,
but the patch called $result->fetchAssociative() — a Doctrine DBAL method that doesn't exist on
Nextcloud's OC\DB\ResultAdapter. That raises \Error, and the surrounding catch (\Exception)
does not catch \Error, so the fatal escaped and killed the CalDAV PUT. The Calendar UI just
showed its generic "Failed to save event"; the real error was only ever in data/nextcloud.log.

Fix (2026-07-13): fetch() instead of fetchAssociative(), an is_array() guard, and
catch (\Throwable) so any future failure here falls back to the system mailer instead of 500-ing
the save. No restart needed (opcache.validate_timestamps=On); it is live now.

Verified:

  • CalDAV PUT with an attendee -> HTTP 201 (was 500)
  • bcos-mail: from=<johannes@bcos.cloud> to=<...> status=sent — invite goes out from the organizer's
    own address
    , not noreply, which is what this issue asked for
  • External delivery confirmed by a real recipient on an external domain

@tristan — please create a meeting with an external attendee and confirm it both saves and that the
invite arrives. If Outlook desktop is slow to show it but your phone gets it, that's client-side
sync, not the send path.

Follow-up filed as #2: this patch lives only in the running container and will silently revert on the
next image bump or --force-recreate.

## Fixed and live — please verify Root cause was **not** a permissions or external-recipient problem, and it was worse than the title suggests: since 2026-06-29, saving an event with **any** attendee (internal or external) failed for **every** user with "Failed to save event". The 2026-06-29 attempt to fix this issue patched core Nextcloud (`apps/dav/lib/CalDAV/Schedule/IMipPlugin.php`) to send invites from the organizer's own mail account, but the patch called `$result->fetchAssociative()` — a Doctrine DBAL method that doesn't exist on Nextcloud's `OC\DB\ResultAdapter`. That raises `\Error`, and the surrounding `catch (\Exception)` does **not** catch `\Error`, so the fatal escaped and killed the CalDAV `PUT`. The Calendar UI just showed its generic "Failed to save event"; the real error was only ever in `data/nextcloud.log`. **Fix (2026-07-13):** `fetch()` instead of `fetchAssociative()`, an `is_array()` guard, and `catch (\Throwable)` so any future failure here falls back to the system mailer instead of 500-ing the save. No restart needed (`opcache.validate_timestamps=On`); it is live now. **Verified:** - CalDAV `PUT` with an attendee -> **HTTP 201** (was 500) - bcos-mail: `from=<johannes@bcos.cloud> to=<...> status=sent` — invite goes out from the **organizer's own address**, not noreply, which is what this issue asked for - External delivery confirmed by a real recipient on an external domain @tristan — please create a meeting with an external attendee and confirm it both **saves** and that the invite **arrives**. If Outlook desktop is slow to show it but your phone gets it, that's client-side sync, not the send path. Follow-up filed as #2: this patch lives only in the running container and will silently revert on the next image bump or `--force-recreate`.
hiveiq added the Verify Fix label 2026-07-13 13:31:55 -04:00
tristan was assigned by hiveiq 2026-07-13 13:31:56 -04:00
Owner

Correction to my note above: the follow-up is tracked in hiveiq-ops/hiveiq-devops#38 (hiveiq-ops/hiveiq-devops#38), not bcos-office#2 — that one was filed in the wrong repo and is superseded.

This issue (#1) is unaffected: the fix is live, and it stays open pending @tristan's verification.

Correction to my note above: the follow-up is tracked in **hiveiq-ops/hiveiq-devops#38** (https://hiveiq-gitea.directlx.dev/hiveiq-ops/hiveiq-devops/issues/38), not `bcos-office#2` — that one was filed in the wrong repo and is superseded. This issue (#1) is unaffected: the fix is live, and it stays open pending @tristan's verification.
Sign in to join this conversation.