#I have 3 replicas that all respond to the same thing

59 messages · Page 1 of 1 (latest)

wise slate
#

Yo! I have a bot that sends a message when a thread is created, but Im running 3 replicas, so the problem is that they all send the messge at the same time. I tried to resolve this by just checking if the last message was by the bot, but since they all check at once its false for all of them, and all of them end up sending. Any idea how I can resolve this without creating a database / api or creating extra overhead beyond the function itself?

client.on(Events.ThreadCreate, async (thread: ThreadChannel) => {
    if (thread.parent?.name === 'whatever') {
        const lastMessage = (await thread.messages.fetch({ limit: 1 })).first();

        // Checks if the bot has already sent this message
        if (lastMessage && lastMessage?.author.id === thread.guild.members.me?.id) {
            return
        }

        return thread.send({
            content: "whatever"
        })
    }
})
hasty hedgeBOT
#
  • What's your exact discord.js npm list discord.js and node node -v version?
  • Not a discord.js issue? Check out #1081585952654360687.
  • Consider reading #how-to-get-help to improve your question!
  • Explain what exactly your issue is.
  • Post the full error stack trace, not just the top part!
  • Show your code!
  • Issue solved? Press the button!
royal granite
#

Why do you have three of the same bot running?

wise slate
magic drum
#

that doesn't quite make sense

#

redundancy for?

wise slate
#

how? Someone crashes one of them and the bot still survives?

#

2 instances left while the last one restarts

magic drum
#

crashes how exactly? you need to make your code so it cannot be crashed easily

wise slate
#

obv but edge cases exist

magic drum
#

crashes how exactly?

wise slate
#

I dont know, if I knew I would fix it

#

But things in production may crash if something that isnt supposed to happen happens

#

and in that case we have redundancy

magic drum
#

thats why you test with dev bots before production

wise slate
#

yes

magic drum
#

i personally do not see the reasoning behind this

wise slate
#

Because bugs can still happen even if you test it?

uneven flame
#

restarting is pretty fast, and you shouldn't have crashes often anyway

wise slate
#

this is besides the point tho

#

and doesnt help with solving the problem im facing

magic drum
#

the problem is that you do not need 3 instance of your bot running if you have a crash. simply adjust your code so you can prevent crashes. thats what the developers ultimate goal. none of this is related to discord.js in any way

wise slate
#

How is it not related? Im looking for a method to interact with the discordjs api to avoid an issue with a discordjs bot?

#

its a goal yeah but the world isnt perfect ^^

#

its not like facebook has one instance running because they dont make mistakes

#

sure it restarts fast but that doesnt help

#

if its down its down

royal granite
#

You can utilize a timeout to wait a few seconds and then fetch the last message and check if it's from the bot, but that's still incredibly inefficient and you're making multiple API calls to make up for the fact that you're not addressing the root cause of the crashes

#

You don't see bot projects doing this because it doesn't scale at all

keen hollow
#

What you're attempting to do to achieve redundancy is lacking a key component called load balancing.

Having three whole complete bots running at once with no other changes will result in what is happening here - three events being processed three times causing three responses.

Conceptually, the way you should handle this is to have a single incoming point of traffic (the websocket) that can send the event to be processed on any one of multiple servers, by checking that it's running first. This is essentially how websites scale to handle load.

But discord.js does not support this decoupling. You'd have to build it yourself using the modules (/ws, /rest, /core etc)

#

The other thing to consider here is that redundancy is better at address hardware failures. If one of your bots crashes because of an error in the code, the other two will crash too because the same error exists there.

wise slate
wise slate
wise slate
#

but Ive investigated it a lot now and it seems there is no way except sharding that will solve this

keen hollow
keen hollow
wise slate
#

🤷‍♀️

#

Try it ig

wise slate
keen hollow
#

Yes

wise slate
#

alright

#

then im forced to scale down ig

keen hollow
#

Or not use discord.js, yeah

wise slate
#

options?

#

without switching language

keen hollow
#

In my personal opinion though, without knowing how big your bot is, it's really not worth it

wise slate
#

yeah I skipped over that part, thats what I said in the initial message

#

'without api / database'

#

will rather focus resources on other projects its not a major issue

#

I assumed so, but it was worth a try, might have been some hacky workaround

#

the timeout idea would have been perfect if they didnt store the reply

glossy iron
#

make a endpoint to check health

wise slate
#

breaks the constraint of not having things outside of the bot

#

Like everything should be in the bots code, it should be a single bot, not have an api or database or be environment dependant, and not require maintenance

#

also then it needs to be down for the healthcheck to work, even 5s downtime is too much, im looking for a solution that is always online

jovial pumice