HTTP 500 when converting Meeting Proposal to Event: SQL Unique Constraint Violation on UID

[shbb-asdea]

Steps to reproduce

Create a new Meeting Proposal (Poll) in the Calendar web interface.

Add participants and dates.

Have a participant (or yourself) vote for a date.

Open the proposal as the owner.

Click the "Create" (or "Crea") button on the confirmed date to finalize the meeting.

Expected behavior

The "Meeting Proposal" (draft) should be deleted/converted, and a new "Event" should be created in the calendar with the details from the proposal.

Actual behavior

The UI shows a loading spinner that eventually stops or fails. The browser console shows a 500 Internal Server Error on the POST /apps/calendar/v1/proposal/convert (or similar endpoint). The backend logs show a SQLSTATE[23505]: Unique violation error regarding calobjects_by_uid_index.

Calendar app version

6.1.5

CalDAV-clients used

N/A (Issue occurs in Nextcloud Web Interface)

Browser

Firefox 147.0 (but issue is server-side)

Client operating system

Ubuntu Linux (but issue is server-side)

Server operating system

Linux (Docker Container)

Web server

Other

Database engine version

PostgreSQL

PHP engine version

PHP 8.4

Nextcloud version

32.0.3

Updated from an older installed version or fresh install

Fresh install

List of activated apps

- calendar: 6.1.5
- calendar_resource_management: 0.11.0
- spreed: (enabled, version unknown from provided snippet but active)
...and others standard for Docker image

Nextcloud configuration

Standard Docker configuration.

Web server error log

192.168.1.33 - - [30/Jan/2026:11:40:15 +0000] "POST /ocs/v2.php/calendar/proposal/convert HTTP/1.1" 500 823 "-" "Mozilla/5.0 ..."

Log file

{
  "reqId": "...",
  "level": 3,
  "time": "2026-01-30T11:40:15+00:00",
  "remoteAddr": "...",
  "user": "boris.shestakov",
  "app": "index",
  "method": "POST",
  "url": "/ocs/v2.php/calendar/proposal/convert",
  "message": "An exception occurred while executing a query: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value violates unique constraint \"calobjects_by_uid_index\"\nDETAIL:  Key (calendarid, calendartype, uid)=(30, 0, 9d8aa045-d371-49c1-9f70-xxxx) already exists.",
  "exception": {
    "Exception": "Doctrine\\DBAL\\Exception\\UniqueConstraintViolationException",
    "Message": "An exception occurred while executing a query: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value violates unique constraint \"calobjects_by_uid_index\"...",
    "File": "/var/www/html/lib/private/DB/Exceptions/DbalException.php",
    "Line": 56
  }
}

Browser log

XHR POST https://nextcloud.hippohub.lol/ocs/v2.php/calendar/proposal/convert [HTTP/2 500  1352ms]

Additional info

Root Cause Analysis: I investigated the source code in custom_apps/calendar/lib/Service/Proposal/ProposalService.php.

The error occurs because the application attempts to insert the new Event using the same UID as the existing Proposal object before the Proposal is deleted. Since both objects reside in the same database table (oc_calendarobjects) and share the same uniqueness constraint scope (calendar_id + uid), the database blocks the INSERT operation.

In convertProposal method:

The code explicitly attempts to reuse the Proposal's UUID:

// Line ~341 in ProposalService.php $vEvent->UID->setValue($proposal->getUuid() ?? Uuid::v4()->toRfc4122());

The code attempts to persist the new Event (INSERT):

// Line ~372 $userCalendar->createFromString(..., $vObject->serialize());

The code attempts to delete the old Proposal (DELETE):

// Line ~378 $this->proposalVoteMapper->deleteByProposalId(...);

Because step 2 fails with a Unique Constraint Violation, step 3 is never reached.

Temporary Workaround / Proposed Fix: I was able to resolve this by patching ProposalService.php to force the generation of a new UUID for the converted event. This avoids the database collision.

Patch applied:

`
// custom_apps/calendar/lib/Service/Proposal/ProposalService.php

// BEFORE:
// $vEvent->UID->setValue($proposal->getUuid() ?? Uuid::v4()->toRfc4122());

// AFTER (Fix):
$vEvent->UID->setValue(Uuid::v4()->toRfc4122());
`

While reusing the UID is preferred for iCal threading consistency, the current "Insert-then-Delete" logic is incompatible with strict DB constraints when the UID is already taken by the source object. Generating a new UID resolves the crash and ensures data safety (no risk of deleting the proposal if the insert fails).

[SebastianKrupinski]

Hi @shbb-asdea

Thank you for the report, this should already be addressed.

#7831

There is a line that deletes the existing blocker events...

calendar/lib/Service/Proposal/ProposalService.php

Line 365 in e835791

// delete any existing calendar blocker event

I'll retest this.

[shbb-asdea]

Hi @SebastianKrupinski,

Thanks for checking. I've looked at the code snippet you referenced, but I believe the issue lies elsewhere.

The line you pointed out ($this->deleteCalendarBlockersOrganizer) deletes the blocker events, but it does not delete the Proposal object itself from the database.

The conflict (SQLSTATE[23505]: Unique violation) happens because:

Line 341: The new Event is assigned the exact same UID as the existing Proposal:
$vEvent->UID->setValue($proposal->getUuid() ...)

Line 372: The code attempts to INSERT this new Event into the DB:
$userCalendar->createFromString(...)

At this specific moment (Line 372), the original Proposal object still exists in the oc_calendarobjects table with the same UID. The database constraint forbids two objects (the existing Proposal and the new Event) from sharing the same UID within the same calendar, causing the crash.

The deletion of the Proposal itself only happens after the insert attempt, at the very end of the function:

// Line ~383
$this->proposalMapper->deleteById($user->getUID(), $proposal->getId());

Since the code crashes at Line 372, Line 383 is never reached. Deleting the "blocker event" (Line 366) does not free up the UID of the Proposal itself.

That is why my workaround (generating a new random UUID at Line 341) fixes the crash — it avoids the collision with the persisting Proposal object.

Could you please verify if the intended logic is to delete the Proposal before creating the Event, or if the Event is supposed to have a new UID?

[SebastianKrupinski]

Hi @shbb-asdea

The error you posted points to the violation happening in the "calendarobjects" table... the convert command does not re-save the proposal...

{
  "reqId": "...",
  "level": 3,
  "time": "2026-01-30T11:40:15+00:00",
  "remoteAddr": "...",
  "user": "boris.shestakov",
  "app": "index",
  "method": "POST",
  "url": "/ocs/v2.php/calendar/proposal/convert",
  "message": "An exception occurred while executing a query: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value violates unique constraint \"calobjects_by_uid_index\"\nDETAIL:  Key (calendarid, calendartype, uid)=(30, 0, 9d8aa045-d371-49c1-9f70-xxxx) already exists.",
  "exception": {
    "Exception": "Doctrine\\DBAL\\Exception\\UniqueConstraintViolationException",
    "Message": "An exception occurred while executing a query: SQLSTATE[23505]: Unique violation: 7 ERROR:  duplicate key value violates unique constraint \"calobjects_by_uid_index\"...",
    "File": "/var/www/html/lib/private/DB/Exceptions/DbalException.php",
    "Line": 56
  }
}

It looks like the issue is in one of the indexes of the "calendarobjects" table...

duplicate key value violates unique constraint \"calobjects_by_uid_index\"\nDETAIL:  Key (calendarid, calendartype, uid)=(30, 0, 9d8aa045-d371-49c1-9f70-xxxx) already exists.

I am thinking this might be caused by database lag, the index key is not removed yet, after we delete the blocker event, and we start creating another entry with the same uid key.

[shbb-asdea]

Hi @SebastianKrupinski,

I respectfully disagree regarding the "database lag" theory. The issue appears to be strictly synchronous and related to the Order of Operations in the code.

Please consider the state of the oc_calendarobjects table step-by-step:

Initial State: The table contains the Proposal Object (VPOLL) with UID = X.

Line 366: deleteCalendarBlockersOrganizer is called. This removes the blocker event, but the Proposal Object (UID = X) remains in the table.

Line 372: $userCalendar->createFromString(..., UID = X) is called.

    The code attempts to INSERT a new Event with UID = X.

    CRASH: The database rejects this because the Proposal Object (from Step 1) is still holding UID = X. The Unique Constraint calobjects_by_uid_index is violated.

Line 383: $this->proposalMapper->deleteById(...) is supposed to delete the Proposal.

    This line is never reached because of the crash at Step 3.

The conflict is not between the Blocker and the New Event. The conflict is between the Existing Proposal and the New Event.

Since the Proposal is only deleted after the attempt to create the Event, the UID is never free during the INSERT command.

This confirms why generating a new random UUID (my workaround) fixes the issue immediately — it bypasses the collision with the persisting Proposal object.

Could you confirm if the intention was to delete the Proposal object before creating the Event?

[sobeaa]

Update: still reproducible on NC 32.0.6 / Calendar 6.2.0 (PostgreSQL)

We are seeing the same unique constraint violation in a production environment when processing calendar invitations.

Environment

• Nextcloud: 32.0.6
• Calendar app: 6.2.0
• Database: PostgreSQL 17.8
• PHP: 8.3

What triggers it

• User receives a calendar invitation via email
• User accepts the invitation
• Nextcloud returns Internal Server Error

Error (server log)

SQLSTATE[23505]: Unique violation:
duplicate key value violates unique constraint "calobjects_by_uid_index"
Key (calendarid, calendartype, uid)=(..., 0, <UID>) already exists.

Relevant flow

• Occurs during CalDAV scheduling (Sabre\CalDAV\Schedule\Plugin)
• Observed in both REQUEST and REPLY handling
• Fails on INSERT into oc_calendarobjects

Observation

• A calendar object with the same UID already exists in the same calendar
• The operation attempts to INSERT instead of updating/replacing the existing object

Impact

• Users cannot accept calendar invitations
• Error is surfaced as a generic Internal Server Error

[shbb-asdea]

@sobeaa you can use my fix at the moment

// custom_apps/calendar/lib/Service/Proposal/ProposalService.php

// BEFORE:
// $vEvent->UID->setValue($proposal->getUuid() ?? Uuid::v4()->toRfc4122());

// AFTER (Fix):
$vEvent->UID->setValue(Uuid::v4()->toRfc4122());

[SebastianKrupinski]

This should now be resolved with the v6.2.2 last week

#8092

[shbb-asdea]

Hi @SebastianKrupinski,

I’ve tested the latest changes, but unfortunately, the issue is not resolved. The fix in #8092 (handling blocker events) addresses a different symptom, but doesn't fix the root cause I described earlier.

The core conflict is not between "blockers" and the event, but between the Proposal object (VPOLL) and the new Event (VEVENT) itself.

Even in the latest version, the execution flow remains:

Line ~372: $userCalendar->createFromString(...) — The app tries to INSERT the new Event using the Proposal's UID.

Database Error: Since the original Proposal object is still in the oc_calendarobjects table with that same UID, the unique constraint calobjects_by_uid_index triggers a 500 error immediately.

Line ~383: $this->proposalMapper->deleteById(...) — This cleanup code is never reached because the process crashed at step 1.

To fix this, the Proposal must be deleted before the new Event is created, or the Event must be assigned a unique UID (as per my workaround).

Could you please reopen this or let me know if I should provide a new trace showing that the collision is specifically with the VPOLL record?

Thanks!