🐛 Bug: tsdav deleteObject() does not delete calendars on Radicale

[PhilflowIO]

Description

The tsdav.deleteObject() method returns success (no error thrown) but does NOT actually delete calendars on Radicale server. The calendar remains on the server after the call.

Discovered during: Integration test debugging (caldav-005 test) on 2025-10-10

Environment

• Server: Radicale (https://radicale.philflow.me)
• tsdav version: Latest from PhilflowIO/tsdav#master
• Auth method: Basic Auth

Steps to Reproduce

import { createDAVClient } from 'tsdav';

const client = await createDAVClient({
  serverUrl: 'https://radicale.philflow.me',
  credentials: { username: 'admin', password: 'xxx' },
  authMethod: 'Basic',
  defaultAccountType: 'caldav',
});

// Fetch calendars
const calendars = await client.fetchCalendars();
console.log('Calendars before:', calendars.length); // e.g., 1

// Try to delete calendar
await client.deleteObject({ url: calendars[0].url });
console.log('✅ deleteObject() succeeded (no error thrown)');

// Verify deletion
const calendarsAfter = await client.fetchCalendars();
console.log('Calendars after:', calendarsAfter.length); // Still 1!

Expected Behavior

• deleteObject() should delete the calendar
• Subsequent fetchCalendars() should not show the deleted calendar

Actual Behavior

• deleteObject() returns success (no error)
• Calendar still exists on server
• fetchCalendars() still shows the calendar

Workaround

Use direct HTTP DELETE request instead of tsdav client:

const response = await fetch(calendar.url, {
  method: 'DELETE',
  headers: {
    'Authorization': `Basic ${Buffer.from(`${username}:${password}`).toString('base64')}`,
    'Content-Type': 'text/calendar; charset=utf-8',
  },
});

if (response.ok || response.status === 204 || response.status === 404) {
  console.log('✅ Calendar actually deleted');
}

Impact

• HIGH - Affects all calendar deletion operations
• Test infrastructure cleanup was failing silently
• The delete_calendar MCP tool may need updating
• Users think calendars are deleted when they're not

Testing Needed

• Verify if bug exists on Nextcloud
• Verify if bug exists on Baikal
• Verify if bug exists on iCloud
• Determine if this is a tsdav bug or Radicale-specific quirk
• Consider reporting to tsdav upstream if universal

Files Affected

• tests/integration/setup-test-data.js (lines 456-474) - Uses HTTP DELETE workaround
• src/tools.js - delete_calendar tool may need update

Additional Context

This bug was hard to detect because:

• No error is thrown (appears successful)
• Only discovered when verifying actual server state
• Test cleanup appeared to work but calendars accumulated

See known_bugs.md for detailed documentation.

[PhilflowIO]

🔍 Testing Results - Bug Confirmed as Radicale-Specific

Test Results:

Server	deleteObject() Status	Result
Radicale	❌ FAILS	Calendar remains after deleteObject() call
Nextcloud	✅ WORKS	Calendar successfully deleted
Baikal	⚠️ UNTESTED	No calendars available for testing

Evidence:

# Nextcloud Test (2025-01-11):
📋 Existing calendars on Nextcloud: 1
🎯 Testing with calendar: https://nextcloud.philflow.me/remote.php/dav/calendars/admin/team-meetings-calendar/
🗑️ Attempting deleteObject()...
✅ deleteObject() succeeded (no error thrown)
📋 Calendars after delete: 0
✅ deleteObject() worked correctly on Nextcloud

Conclusion:

This is a Radicale-specific bug, not a tsdav issue. The deleteObject() method works correctly on standard CalDAV servers like Nextcloud.

Recommendation:

• For Radicale users: Implement workaround in MCP server
• For other servers: No action needed - works correctly
• For tsdav maintainers: This is not a tsdav bug, but a Radicale server issue

Next Steps:

1. Document Radicale workaround in MCP server
2. Add server-specific handling for calendar deletion
3. Update documentation to note Radicale limitations