After a night of debugging finnally found the root cause with Ai
When creating a meeting proposal with multiple proposed dates, the backend correctly generates a single VEVENT containing all dates via RDATE entries. These appear properly in the calendar UI as multiple tentative occurrences.
However, the blocker‑detection logic only evaluates the event’s DTSTART value and ignores all additional dates stored in RDATE. As a result:
Only the first proposed date is treated as a calendar blocker.
Subsequent proposals do not detect conflicts with the other proposed dates.
The frontend receives only one “blocked” date and displays only that one.
Availability checks and proposal views behave as if the proposal had only a single date.
The blocker event itself is correct — the issue is that the code reading blocker events does not parse RDATE values.
Expected behavior:
All proposed dates (DTSTART + RDATEs) should be treated as individual blocked times when evaluating availability or rendering proposal conflicts.
Actual behavior:
Only the first date (DTSTART) is considered blocked; all RDATE occurrences are ignored.
Root cause:
Blocker‑reading logic uses only DTSTART and does not iterate over RDATE entries.
Fix direction:
Extend blocker detection to extract all occurrences from VEVENTs by reading both DTSTART and all RDATE values.
=> Will try to make a proposal
After a night of debugging finnally found the root cause with Ai
When creating a meeting proposal with multiple proposed dates, the backend correctly generates a single VEVENT containing all dates via RDATE entries. These appear properly in the calendar UI as multiple tentative occurrences.
However, the blocker‑detection logic only evaluates the event’s DTSTART value and ignores all additional dates stored in RDATE. As a result:
Only the first proposed date is treated as a calendar blocker.
Subsequent proposals do not detect conflicts with the other proposed dates.
The frontend receives only one “blocked” date and displays only that one.
Availability checks and proposal views behave as if the proposal had only a single date.
The blocker event itself is correct — the issue is that the code reading blocker events does not parse RDATE values.
Expected behavior:
All proposed dates (DTSTART + RDATEs) should be treated as individual blocked times when evaluating availability or rendering proposal conflicts.
Actual behavior:
Only the first date (DTSTART) is considered blocked; all RDATE occurrences are ignored.
Root cause:
Blocker‑reading logic uses only DTSTART and does not iterate over RDATE entries.
Fix direction:
Extend blocker detection to extract all occurrences from VEVENTs by reading both DTSTART and all RDATE values.
=> Will try to make a proposal