Discourse-automation did not send PM: no valid targets exist

AI-generated summary

The issue discusses a bug in the Discourse-automation plugin where PMs fail to send due to username changes between trigger and delivery. pangbo notes that the plugin uses usernames at trigger time, not the current ones, leading to failures when users rename their accounts. They suggest storing user IDs instead of usernames in DiscourseAutomation::PendingPm to resolve this. sam adds that this is part of a deeper issue, as PostCreator historically didn’t support user IDs, and a recent change aims to make such behavior more predictable and reliable.

I saw some warnings in the logs that discourse-automation plugin failed to send PMs. Automation plugin uses the usernames at the time of triggering the trigger, rather than the latest usernames of users when sending PMs. Since the PM-sending script supports delayed sending, users may change their usernames after the trigger and before the PM is sent, resulting in failures.

I think changing DiscourseAutomation::PendingPm to record user IDs instead of usernames can solve this issue:


Regarding my use case:

I have a task to send PMs to new users after a delay, configuring the automation plugin to send PMs five minutes after users join the TL0 group. However, some new users change their usernames immediately after registration, resulting in sending failures.

2 Likes

It is a surprisingly tricky rabbit hole that goes pretty deep.

When you finish digging you discover that a fundamental construct we had PostCreator never supported user ids

https://github.com/discourse/discourse/pull/37708

I think it is a great change cause everything is a lot less surprising. Users tend to do a bit of username renaming when they start off.

3 Likes