btw, to clarify, when I mean batch user queries, I mean use something like UserArray::newFromIds

For 2, whether or not that's important depends on the max number of people you expect to ever subscribe to a newsletter. Currently the signpost has 872 subscribers which I imagine serves as a good upper bound [for now], and that is still in the range where the function performs ok. So its probably ok to leave the function as it is for initial deployment, with a code comment saying it might have to be split up in the future if the extension becomes wildly popular.

I'm guessing this is talking about the implementation of the onEchoGetDefaultNotifiedUsers hook? :)

In T110535#1584877, @Addshore wrote:

I'm guessing this is talking about the implementation of the onEchoGetDefaultNotifiedUsers hook? :)

yeah.

In T110535#1583750, @Qgil wrote:

If 1000 subscribers is an OK limit, I think we could start with that assumption. We will have time to react if a newsletter if reaching that limit (unless this extension is so successful that we get newsletters with 5000 subscribers overnight, but in that case we will have other problems). :)

The function would probably be ok even up to 5000 subscribers. I'd start to be concerned if there was something with 10,000 subscribers (Maybe. These numbers are all pulled out of my hat, I don't really know)

First part of this was done in https://gerrit.wikimedia.org/r/241070. Regarding the second part, I believe Echo already uses the job queue for sending notifications (unless we explicitly set it to not use the job queue). Hence closing this as resolved.

However, on Wikimedia wikis, the job queue is used on group0 wikis only currently. So we might need to change that in the future (if it's not done on Echo by then) but it should work for initial deployment. See T101050 and T99573.