SOLVED! ~Bug: Creating a calendarEvent returns 201, but nothing is created~

[Bredo]

Bug Description

When creating a calendarEvent with the REST API, I get a 201 created back, alongside a the new object.
I can also query that object by ID (find one calendar event), but if I search for it either by API or on the /objects/calendarEvents page, it doesn't show up.

Expected behavior

• That Create One calendar event is blocked if it's not surfaced - OR
• That manual calendar events can be searched and is shown as any other object entry

Feature request

I'll write a separate feature request later, on having "create calendar event" as a core capability, both as a logic function in workflows, as well as available in the SDK. This would likely be a "blind" create capability, awaiting the calendar platform to accept the change, and then propagate it with the standard polling

[sonarly[bot]]

🟡 Sonarly Analysis — Medium Severity

CalendarEvent visibility hook hides manually created events

REST create calendarEvent can return 201, but the record is hidden from list/search flows because it has no calendar-channel association. This creates a confusing “created but not visible” state.

Root Cause

calendarEvent.findMany/findOne post-hooks apply visibility restrictions that assume each event is linked to at least one calendarChannelEventAssociation. When no association exists, the hook falls through to calendarEvents.splice(i, 1) and removes the event from query results.

Evidence:

• CalendarEventFindManyPostQueryHook and CalendarEventFindOnePostQueryHook both call ApplyCalendarEventsVisibilityRestrictionsService.applyCalendarEventsVisibilityRestrictions(...) for calendar events.
• In apply-calendar-events-visibility-restrictions.service.ts, events are removed unless they match SHARE_EVERYTHING, owner-connected-account, or METADATA paths; otherwise the final branch is:
  • calendarEvents.splice(i, 1);
• There is no calendar-event create hook enforcing/creating a channel association before allowing create.
• Import path explicitly creates associations for newly created events (calendar-save-events.service.ts inserts calendarChannelEventAssociation), which is why imported events are visible while manually created ones can become “orphan” and hidden.

Why it failed now (triggering cause):

• This is not a fresh regression in the hiding logic; the behavior originated when this visibility post-hook was introduced (commit 521e75981a900d4e1a720220e5c995c435f53039).
• The incident is triggered by a traffic/use-case change: creating calendarEvent directly via REST (outside the import pipeline) produces unassociated events, which the existing post-hook intentionally filters out.
• Recent commits in this area are refactors/perf/auth-context adjustments, not a semantic change to the “drop unassociated events” behavior.

So the proximate cause is the post-query visibility filter deleting orphan events from result sets; the triggering cause is manual REST creation of calendar events without the association lifecycle that import jobs provide.

Blame commit: 521e7598 by etiennejouan — Fix calendar events & messages fetching + fix timeline design (#11840)

Suggested Fix

I first checked recent history on the affected files (git log --all --oneline --since='30 days ago' -- ...) and reviewed relevant commits (e485b679eaa, 6cd069ce40c, 4b873a2b933). None implemented this orphan-event visibility fix.

I then fixed the issue in the visibility restriction service by treating unassociated calendar events as visible instead of filtering them out:

• In apply-calendar-events-visibility-restrictions.service.ts, added an early continue when associations.length === 0.
• This prevents manually created/orphan calendarEvent records from being removed by the final splice fallback.

To prevent regression, I added a unit test in the existing spec:

• apply-calendar-events-visibility-restrictions.service.spec.ts now includes should return calendar event when it has no calendar channel association.
• The test verifies the event remains in results and that channel/account lookups are not triggered for that case.

---

Analyzed by Sonarly · View full analysis

[Amresh-01]

i want to work on this issue

[abinash-thakur]

brother i am allready working on this issue

[Amresh-01]

Ok thanks for clearification