Scheduled Talk meetings: invited calendar attendees hit "The conversation does not exist"

[khnjrdm]

Tip

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Summary

Attach a Talk conversation to a calendar event and invite people. When they click the meeting link at the scheduled time, they get "The conversation does not exist. Join a conversation or start a new one!"
The calendar event is correct. The Talk room exists on the server. The invited person's Nextcloud email matches the calendar attendee's email exactly. They accepted the meeting. It is meeting time.
They still cannot join.
Not a broken link. Not a lookup failure. Not a permission-denied. Talk refuses and returns the least helpful error it could have chosen: an error that blames the sender for a link that is not actually broken.

Steps to reproduce

1. Create a new calendar event in the Nextcloud Calendar UI.
2. Click "Add Talk conversation" to attach a Talk room to the event.
3. Save the event.
4. Add an attendee by email. Choose an address that matches an existing Nextcloud user's registered email exactly.
5. Send the invitation. The recipient accepts.
6. At the scheduled meeting time, the invited user clicks the Talk link.
7. They see "The conversation does not exist."

Expected behaviour

The invited attendee ends up in the Talk room's participant list. Ideally at the moment they are added to the event, or at least at the moment they accept, or at the very worst at the moment they click the link. Either way, they can join.
If the email cannot be resolved to a Nextcloud user, they are treated as a guest and the room admits them accordingly. They should never see "conversation does not exist" for a room that does exist and is theirs to join.

Actual behaviour

The invited attendee is never added to the Talk room's attendee list. The oc_talk_attendees table for the room contains only the organiser. The invited user, visible in the calendar as "Accepted", is invisible to Talk. Talk correctly refuses their join. It just says the wrong thing about why. It says the room does not exist.

Root cause (verified against 33.0.6.2 sources)

Look in apps/spreed/lib/Listener/CalDavEventListener.php. The listener subscribes to CalendarObjectCreatedEvent, CalendarObjectUpdatedEvent, and CalendarObjectMovedToTrashEvent. On create and update it calls handleCalendarEventUpdate($event->getObjectData()).
That handler updates the room's metadata. Name, description, times. It does not synchronise the event's ATTENDEE list into the Talk room's participant list. Room membership is populated once, at room creation, in RoomService. Everything that happens to the attendee list after that stays in the calendar and never reaches Talk.
The practical consequences:

• Attendees added after the Talk room was created are never added to Talk.
• Attendees whose RSVP arrives via a non-organiser client (Mac Calendar over CalDAV, Outlook, Google-synced clients) may be filtered out by the isEventOnOrganizersCalendar guard even if their update did reach the listener.
• A room attached to an empty event admits only the organiser. Every attendee added after that has to be added by hand.

Impact

Anyone coming from Teams, Meet, Zoom or Webex will try this workflow first. It is the workflow the calendar UI advertises: create event, attach Talk, invite people, done. On Nextcloud, that workflow does not work. It fails at meeting time, silently up to that point, and with an error that makes the organiser look incompetent.
The failure is particularly unforgiving:

• The user gets no clue that Talk keeps its participant list separate from the calendar's attendee list.
• The error message says the room does not exist. It does exist. The user is looking at the door of the room but the door is telling them the building was demolished.
• The organiser has no indication that anything is wrong until people start asking why the link is broken. There is no admin warning, no UI hint, no in-event flag.
• By the time it is discovered, the meeting has started or been missed.
  I hit this on Nextcloud 33.0.6.2 with Talk 22.x, in a workflow identical to the one in [Bug]: CalDAV doesn't add new attendee to the associated Talk room when adding via CalDAV server#51212 filed early last year. The behaviour has not changed.

Suggested resolution

The CalDavEventListener should do more on CalendarObjectUpdatedEvent than update metadata. Specifically, it should:

1. Compare the event's current ATTENDEE list against the room's current oc_talk_attendees list.
2. For each calendar attendee not already in the room, try to resolve their email to a Nextcloud user.
3. If resolution succeeds, add them to the room as participant_type = 3.
4. If resolution fails because the email is not a known Nextcloud user, and the room permits guests, add them as a guest with an access_token. If it does not permit guests, log a warning that the organiser can find (and, ideally, surface in the calendar UI).
5. Do not remove attendees from the room when they are removed from the event. Participation history is worth keeping. This matches the discussion in Assign attendees as Talk room participants when creating a room from an event calendar#5376.

The isEventOnOrganizersCalendar guard also needs revisiting. It currently prevents attendee syncs that originate from a non-organiser client. That covers a lot of legitimate RSVP flows: MacOS Calendar over CalDAV, Outlook, phones. All of them are ruled out of the sync path.

Environment

• Nextcloud Server: 33.0.6.2
• Talk (spreed): 22.x (bundled)
• Calendar: latest available for NC 33
• PHP 8.x, MariaDB / MySQL
• Reverse proxy: Apache 2.4

Evidence

oc_talk_attendees for a scheduled meeting room whose calendar event has two accepted attendees:

+-----+------------+-----------+------------------+------------------+
| id  | actor_type | actor_id  | participant_type | invited_cloud_id |
+-----+------------+-----------+------------------+------------------+
| 447 | users      | organiser |                1 | NULL             |
+-----+------------+-----------+------------------+------------------+

The organiser is there. The accepted attendee, whose Nextcloud email matches the calendar attendee address exactly, is not.

The calendar event stored in oc_calendarobjects shows both attendees, with the second having PARTSTAT=ACCEPTED. The two data stores disagree. Talk's is wrong.

References to existing issues

• [Bug]: CalDAV doesn't add new attendee to the associated Talk room when adding via CalDAV server#51212, "CalDAV doesn't add new attendee to the associated Talk room when adding via CalDAV" (open since 2025-03-03).
• Add/Remove attendees to/from associated Talk room when changed via CalDAV #15720, "Add/Remove attendees to/from associated Talk room when changed via CalDAV". Reclassified from bug to feature request. Open since 2025-03-04.
• Assign attendees as Talk room participants when creating a room from an event calendar#5376, "Assign attendees as Talk room participants when creating a room from an event" (open since 2023-07).
  I am filing a fresh issue rather than adding to the existing three, for three reasons.
  The behaviour manifests as a broken meeting invitation, not a missing power-user feature. Reclassifying it from bug to feature request in spreed#15720 was, respectfully, the wrong call. A room membership that silently diverges from the calendar attendee list is a data-consistency defect. The user-facing symptom is a false error message. Both belong on the bug track.
  All three referenced tickets have gone quiet without a decision on scope or ownership. Cross-app issues sometimes languish because each team assumes the other will pick them up. A new issue is a fresh occasion for someone to.
  The problem is still current on the latest stable release. It is not fringe. Anyone who schedules meetings the way Teams or Meet users are used to will hit it, and unless they know to check the participant list against the calendar attendees they will not know why the link failed until it is too late to matter.

[Antreesy]

Thanks for report!

Yes, attendees list us not synced after creation, only event name/description/start/end to my knowledge. Need to clarify, if Talk should sync it, or Calendar should own the logic to add/remove participants to the room