Hmm, is this the bug where users are added/removed to the same list over and over again? Anyway, that's totally fair, but I'm curious why your tool does this.

So when we see something on the firehose that triggers automation, we don’t check each repo to confirm it hasn’t been labeled already, we just make the call to emitEvent#modEventLabel. Ozone issues the label over the firehose, regardless of whether a repo or post is already labeled.

This means it gets picked up by the tooling to add an account to the list whenever that tool sees the label event in the firehose.

We don’t check because it’s expensive, in terms of rate limiting.

Do you do the same when adding to lists? I guess you just add to the lists even if the list already contains it, similar to labels. We are also limited by what we ingest via the firehose, so fixing this isn't trivial for us. But we'll see what we can do.

We don’t because it’s also non-trivial. We’d have to completely rewrite the program to either pull the list and parse the entire thing each time we added a user (or more likely, add local storage).

It’s a bug in our tooling for sure, just not a high priority given constraints and the fact that absent listifications, would only be visible to us

Anyway, thanks for looking into it!

Yeah, basically same for us. We'd need to store the lists each user is a part of (something which we explicitly wanted to avoid in designing listifications). But maybe we can do something similar by reading the messages we have already sent to a user. Though that may mean we'll hit our rate limits.