update_calendar_event silently overwrites fields with empty strings

[davidgut1982]

Bug: Empty string arguments silently wipe CalDAV event data

Affects PRs: #48, #53

What happens

When update_calendar_event is called and the caller passes empty strings ("") for fields they don't intend to change, the implementation treats those as valid updates and overwrites the existing CalDAV event data with blank values. The call returns success, so there is no indication anything went wrong.

Real-world trigger: An AI assistant called update_calendar_event specifying only participants but passed "" for title, location, start, and description. The result was a CalDAV event with correct ATTENDEE lines but blank SUMMARY, DTSTART, DTEND, LOCATION, and DESCRIPTION — effectively destroying the event while appearing to succeed.

Root cause

The field guards likely look like this:

// Current (buggy): empty string passes the check
if (title !== undefined) {
  vevent.updatePropertyWithValue('summary', title);
}

An empty string is not undefined, so "" gets written to the CalDAV property, overwriting whatever was there.

Fix

Guard each string field against undefined, null, and "":

// Fixed: empty string is treated as "not provided"
if (title !== undefined && title !== null && title !== '') {
  vevent.updatePropertyWithValue('summary', title);
}

Apply the same triple-check to location, description, start, and end (or whichever date/time fields are strings in the API).

Exception — participants array: An empty array [] is a legitimate way to remove all attendees, so it should keep its current !== undefined guard and not be filtered out.

Summary of changes needed

Field	Guard to use
title	!== undefined && !== null && !== ''
location	!== undefined && !== null && !== ''
description	!== undefined && !== null && !== ''
start / end	!== undefined && !== null && !== ''
participants	!== undefined (keep as-is)

Why this matters

Callers — especially LLM-driven tool users — often fill unused parameters with empty strings rather than omitting them entirely. Without this guard, any such call silently destroys event data with no error or warning.

Happy to help test or review once the fix lands in #48 or #53. Thanks for the work on calendar support!

[JonathanGodley]

This is fixed in PR #53 (the calendar-attendee-support branch), which the issue already lists under "Affects PRs."

update_calendar_event now loud-rejects empty/whitespace/null on title, description, and location instead of silently blanking the property (the error tells you to omit the field to leave it unchanged). To deliberately delete an optional field, there's a new clearFields array (allowed: description, location); setting and clearing the same field in one call is rejected. Dates already threw on invalid input, so they were never corrupted.

While fixing this I also found and fixed a related malformed-VEVENT bug: participants: [] removed all ATTENDEEs but left a dangling ORGANIZER. It now strips ORGANIZER too when clearing all participants.

@davidgut1982 — you offered to test; the branch in #53 has it if you'd like to try.

[MadLlama25]

For the record: this shipped in v1.11.0. update_calendar_event loud-rejects empty/whitespace/null on title/description/location, deliberate deletion goes through the new clearFields array (set-and-clear in one call is rejected), and participants: [] now also strips the dangling ORGANIZER. Verified in the release's live test cycle — an empty-title update is rejected and the event confirmed intact afterwards. Thanks for the precise report, @davidgut1982.