[Bug]: Direct frontmatter task completion does not trigger Google Calendar or auto-archive side effects

[martin-forge]

Bug description

Directly editing lifecycle-relevant task frontmatter updates the in-app task data/UI, but does not appear to run the same side effects as completing or updating the task through TaskNotes UI/API paths.

For calendar-eligible one-off tasks, this can leave completed task events visible on Google Calendar and can skip the completed-status auto-archive queue.

Steps to reproduce

1. Use TaskNotes 4.8.1 with Google Calendar export enabled.
2. Enable Google Calendar sync on task create/update/complete/delete.
3. Configure a completed status such as done with isCompleted: true, autoArchive: true, and a non-zero auto-archive delay.
4. Create or use a task with a scheduled date so that it has a Google Calendar event.
5. Directly edit the task note frontmatter outside the TaskNotes task-completion UI path, changing it from:

status: ready
scheduled: 2026-05-18
googleCalendarEventId: <existing event id>

to:

status: done
scheduled: 2026-05-18
completedDate: 2026-05-18
googleCalendarEventId: <existing event id>

6. Let Obsidian/TaskNotes process the file metadata change.

Expected behavior

Lifecycle-relevant direct frontmatter edits should be reconciled consistently with TaskNotes UI/API updates, including Google Calendar projection cleanup and completed-status auto-archive handling.

If direct frontmatter edits are intentionally not a supported side-effect path, that limitation should be clear to users and integrations that write TaskNotes Markdown directly.

Actual behavior

The task data/UI updates, but lifecycle side effects do not consistently run:

• The completed one-off task can remain visible on Google Calendar as a checked/completed event.
• The task is not added to the auto-archive queue even though its completed status is configured for auto-archive.
• Manually archiving the task through TaskNotes later removes the visible calendar projection, which suggests the cleanup works once the normal lifecycle path runs.

Debug info

• TaskNotes version: 4.8.1
• Google Calendar export: enabled
• Sync settings: create/update/complete/delete enabled, trigger both
• Archive settings: move archived tasks enabled; completed status auto-archive enabled
• Reproduced with one-off scheduled tasks, not recurring tasks

Related fixes

This is related to, but distinct from, previous Google Calendar cleanup/retry fixes such as #1695/#1706, #1765/#1769, #1882, and #1883. Those fixes cover cleanup/retry behavior once the relevant lifecycle path runs. This issue is about direct task-file/frontmatter edits not entering that path in the first place.

Notes

A narrow fix could reconcile previous/current task state after direct file updates and route lifecycle-relevant changes through the existing Google Calendar and auto-archive services. Recurrence exception handling, bulk cleanup UI, and vault-specific behavior are out of scope for this issue.

[martin-forge]

I ran a synthetic repro on TaskNotes 4.8.1 to confirm this is not only historical vault drift.

Result:

1. Created a new one-off scheduled task through TaskNotes. TaskNotes created Google Calendar event tk2r1fi00hetscad179jb7vg7k, and the task file received the matching googleCalendarEventId.
2. Directly edited the task file frontmatter from status: ready to status: done, added completedDate, and let Obsidian/TaskNotes process the file change.
3. TaskNotes MCP then read the task as status: done, confirming the file metadata change had been observed.
4. The Google Calendar event was unchanged: title remained the original task title and the description still said Status: Ready.
5. autoArchiveQueue remained empty.
6. Archiving the task through TaskNotes removed the visible calendar event from search and removed googleCalendarEventId from the task file, but the local googleCalendarEventIndex retained the old active task-path entry.

So the direct-file edit path updates TaskNotes' task state, but does not appear to run the calendar completion/update or auto-archive lifecycle side effects.

[callumalpass]

Thank you for reporting this. This should be resolved in release 4.9.0, so I am going to close this issue now.