Skip to content

Reminder email sent to attendee claims the upcoming meeting is with the wrong person (Solution available). #48

Closed

Description

@MinosChatzidakis

Before submitting

  • 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:

  1. Create an event type
  2. In its settings, go to the 'hosts' tab and assign a different host than yourself (the creator of the event type)
  3. In the 'notifications' tab add a notification of your liking
  4. Complete a booking
  5. 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:

  1. Go to /intenal/mailer/mailer.go file
  2. Locate SendReminder function (around line 260)
  3. Within said function, locate the sql query responsible for fetching the booking data
  4. 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).

Calnode version / commit

v0.9.0

How are you running Calnode?

Railway / other PaaS

Logs, screenshots, or anything else

No response

Activity

  1. pullfrog commented on Sep 15, 2026

    @pullfrog
    Contributor
  2. distronode-com commented on Sep 17, 2026

    @distronode-com
    Contributor

    @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.

  3. shockalotti commented on Sep 17, 2026

    @shockalotti
    Contributor

    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.

  4. shockalotti commented on Sep 17, 2026

    @shockalotti
    Contributor

    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.

  5. MinosChatzidakis commented on Sep 18, 2026

    @MinosChatzidakis
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions