[Bug]: Bug / Feature Request: Reminders not triggered when created via file edit & don't recalculate on schedule changes

[garzonjav]

Bug Description

Feature Request / Bug: Reminders not triggered when created via file edit & don't recalculate on schedule changes

Environment

• macOS Tahoe 26.3 (Mac mini 2024, Apple M4)
• Obsidian (minimum app version 1.10.1)
• TaskNotes plugin v4.4.0
• Task identification: Property-based (isTask: true)
• Notification type: System notifications

Description

During testing, we discovered three related issues with the reminder system:

Issue 1: Reminders created via direct file edit don't trigger notifications

When a reminder is added by editing the task's YAML frontmatter directly (e.g., via an external editor or CLI tool), the reminder appears correctly in the Task Reminders UI modal and follows the documented YAML format, but the notification never fires.

Steps to reproduce:

1. Create a task via TaskNotes UI
2. Edit the markdown file directly and add a reminder to the reminders property:

   reminders:
     - id: rem_1773167100000
       type: relative
       relatedTo: scheduled
       offset: -PT5M
       description: 5 minutes before

3. Open the task in Obsidian — the reminder appears in the Task Reminders modal
4. Wait for the reminder time to pass — no notification is triggered

Expected behavior: Reminders written to valid YAML frontmatter should be picked up and registered by TaskNotes when the file is loaded/detected.

Actual behavior: The reminder data is stored in the YAML and displayed correctly in the UI, but the internal notification scheduler never picks it up. The reminder is never registered as an active timer in memory.

Root cause (suspected): When a reminder is created through the TaskNotes UI (bell icon / modal), two things happen:

1. The reminder data is written to the YAML frontmatter
2. An in-memory timer is registered with the notification scheduler

When a reminder is written directly to the YAML frontmatter (via external editor, CLI tool, or script), only step 1 occurs. TaskNotes does not watch for new or modified reminders in the frontmatter, so the scheduler never processes them. The YAML is valid and the UI renders the reminder identically — there is no difference in the data format, no active or registered property, and no visual indicator to distinguish a scheduled reminder from an unscheduled one. The only difference is a runtime state that exists in TaskNotes' memory.

Impact: This prevents external tools (CLI assistants, scripts, automation) from creating functional reminders, limiting TaskNotes' interoperability. Since Obsidian's core value is that notes are plain markdown files editable by any tool, reminders should work regardless of how they are written to the frontmatter.

Issue 2: Relative reminders don't recalculate when scheduled time changes

When a relative reminder (e.g., "5 minutes before scheduled date") is created via the UI, and the scheduled property is subsequently changed (either via file edit or UI), the reminder does not recalculate. It remains tied to the original scheduled time at the moment the reminder was created.

Steps to reproduce:

1. Create a task scheduled for 2:28 PM
2. Add a 5-minute-before reminder via the bell icon (fires at 2:23 PM)
3. Change the scheduled time to 2:40 PM
4. The reminder does NOT fire at 2:35 PM — it was already consumed at the original 2:23 PM

Expected behavior: Since the reminder is defined as relative to the scheduled date (relatedTo: scheduled), it should dynamically recalculate when the scheduled time changes. A "5 minutes before" reminder should always fire 5 minutes before the current scheduled time.

Actual behavior: The reminder offset is resolved to an absolute time at creation and the scheduler never updates it. This is the same underlying issue — the scheduler only processes reminders at the moment they are created through the UI, and does not re-process them when related data changes.

Issue 3: No visual indicator to distinguish scheduled vs unscheduled reminders

Since the only difference between a working reminder (created via UI) and a non-working one (written to YAML) is an in-memory runtime state, users have no way to tell if a reminder will actually fire. Both display identically in the Task Reminders modal — same icon, same formatting, same data.

There is no active, registered, or scheduled property in the YAML to indicate status. The reminder data format is identical regardless of how it was created.

Suggestion: Either:

• Add a visual indicator in the modal (e.g., a green "active" badge vs a grey "unregistered" warning) so users know which reminders will fire
• Or better yet, solve Issues 1 and 2 by having the scheduler watch for frontmatter changes and re-register timers automatically — making this distinction unnecessary

Summary

• Reminder created via UI (bell icon): Notification fires
• Reminder written to YAML via file edit: Notification does NOT fire
• UI reminder after scheduled time changed: Notification does NOT fire (locked to original time)

Suggested improvements

1. Watch for changes to the reminders frontmatter property and register/update notification timers accordingly
2. Recalculate relative reminder times when the related date (scheduled or due) changes
3. Add a visual indicator in the reminder modal to show whether a reminder has an active timer