You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reminder email sent to attendee claims the upcoming meeting is with the wrong person (Solution available). #48
I've searched existing issues and this isn't a duplicate.
This is a reproducible bug in Calnode — not a configuration/setup question or a feature request.
What's the bug?
Hello,
I spotted a weird, albeit easy to fix bug regarding the reminder email that gets sent to the attendee of a meeting, which I was able to fix, and I would like to share the solution here.
The reminder email sent to the attendee claimed that the meeting was to happen with the creator of the event type and not the host who had actually undertaken the meeting. For a one-man team this is fine, but for a setup with multiple people involved it would quickly lead to confusion, as it did in my case.
All emails were sent to the correct addresses, events were appointed to the correct host and saved in the correct calendar, so the sole problem was the name of the host in the reminder email sent to the attendee.
This looked like a background worker mixing things up, and sure enough, after looking around I located the faulty sql query responsible for the mix-up. After consulting the database schema, I managed to resolve the issue with just one change in the query.
Solution: In /internal/worker/worker.go, in the SendReminder function (around line 260), within the sql query replace "JOIN users u ON u.id = et.user_id" with "JOIN users u ON u.id = b.host_id". This will take into account the host the booking has been assigned to and not the user who created the event type.
@shockalotti, given that the fix was pretty straightforward and I already applied it, I would happily open a pr if you want me to.
Steps to reproduce
Steps to reproduce bug:
Create an event type
In its settings, go to the 'hosts' tab and assign a different host than yourself (the creator of the event type)
In the 'notifications' tab add a notification of your liking
Complete a booking
When the time you specified in step 3 comes, the attendee receives an email with the reminder, claiming the meeting is to happen between them and the creator of the event type and not the host it was assigned to (you can see who the meeting was assigned to in the 'bookings' tab)
Steps to resolve bug:
Go to /intenal/mailer/mailer.go file
Locate SendReminder function (around line 260)
Within said function, locate the sql query responsible for fetching the booking data
Replace 'JOIN users u ON u.id = et.user_id ', which cares about the owner of the event type (et) with 'JOIN users u ON u.id = b.host_id', which cares about the host responsible for the upcoming booking (b).
@MinosChatzidakis thanks for tracking this down with the exact fix. It's in #50, credited in the CHANGELOG.
While testing it I found the same owner-for-host lookup in the reschedule path, where it did more damage: the host's reschedule notice went to the event type's owner, so the host actually attending was never told the meeting had moved. #50 fixes that too.
Thanks for the report and the spot-on diagnosis, @MinosChatzidakis - you had the exact line.
Confirmed and fixed: sendReminder joined users on et.user_id (event-type owner) instead of b.host_id (assigned host). While there I found the same shape in loadCancellationData, so cancellation and reschedule emails named the owner too - fixed the same way (confirmation emails were already correct; they load by b.HostID).
Shipped and verified in production with an owner-assigned-to-someone-else booking: the reminder now names the assigned host. Pinned by TestWorker_reminderNamesAssignedHost (prior tests used the same user for owner and host, which is why this slipped through).
Fix is on branch fix/mcp-bearer-archived (commit 27c5265). No need for a separate PR from your side unless you'd like to - happy to credit you here instead.
One more thing, @MinosChatzidakis - your #48 report was the best bug report this repo has ever had: repro steps, root cause, exact fix. Credited you in the changelog.
Two asks: (1) permission to quote your issues (#11, #13, the #33 diagnosis, Greek i18n, #48) as deployer evidence in the v0.10.0 announcement, and (2) if you have cycles, #58 and #59 (both filed today) would benefit from your eye. Thanks either way.
Thank you, I appreciate the kind words.
You can do as you see fit with my issues, I have no issue with you quoting them for the improvement of the app. I am not sure however what you are planning on quoting regarding Greek i18n. I don't think I have contributed to that end, although I'd be glad to.
As for the new issues, I appreciate the trust. I'd be happy to take a shot at it and report my findings in their respective threads.
Activity
pullfrog commentedon Sep 15, 2026
distronode-com commentedon Sep 17, 2026
@MinosChatzidakis thanks for tracking this down with the exact fix. It's in #50, credited in the CHANGELOG.
While testing it I found the same owner-for-host lookup in the reschedule path, where it did more damage: the host's reschedule notice went to the event type's owner, so the host actually attending was never told the meeting had moved. #50 fixes that too.
fix(reminders): name the assigned host, not the event-type owner (#48)
shockalotti commentedon Sep 17, 2026
Thanks for the report and the spot-on diagnosis, @MinosChatzidakis - you had the exact line.
Confirmed and fixed:
sendReminderjoined users onet.user_id(event-type owner) instead ofb.host_id(assigned host). While there I found the same shape inloadCancellationData, so cancellation and reschedule emails named the owner too - fixed the same way (confirmation emails were already correct; they load byb.HostID).Shipped and verified in production with an owner-assigned-to-someone-else booking: the reminder now names the assigned host. Pinned by
TestWorker_reminderNamesAssignedHost(prior tests used the same user for owner and host, which is why this slipped through).Fix is on branch
fix/mcp-bearer-archived(commit27c5265). No need for a separate PR from your side unless you'd like to - happy to credit you here instead.shockalotti commentedon Sep 17, 2026
One more thing, @MinosChatzidakis - your #48 report was the best bug report this repo has ever had: repro steps, root cause, exact fix. Credited you in the changelog.
Two asks: (1) permission to quote your issues (#11, #13, the #33 diagnosis, Greek i18n, #48) as deployer evidence in the v0.10.0 announcement, and (2) if you have cycles, #58 and #59 (both filed today) would benefit from your eye. Thanks either way.
MinosChatzidakis commentedon Sep 18, 2026
Thank you, I appreciate the kind words.
You can do as you see fit with my issues, I have no issue with you quoting them for the improvement of the app. I am not sure however what you are planning on quoting regarding Greek i18n. I don't think I have contributed to that end, although I'd be glad to.
As for the new issues, I appreciate the trust. I'd be happy to take a shot at it and report my findings in their respective threads.