throw error if user presence update fails, or add way to fetch current presence

[JstnMcBrd]

Which application or package is this feature request for?

discord.js

Feature

This is my first time submitting a feature request for d.js, so bear with me.

I've noticed that the client.user.presence member does not actually reflect the client user's presence on Discord - it does not fetch the current presence from Discord. It only reflects the last presence that was set with client.user.setPresence() or .setActivity().

Here's an example. I have a bot that periodically sets the user activity (it must be refreshed regularly because of discord/discord-api-docs#834). I want to make sure that the presence was updated correctly, and if not, throw an error.

const updatedPresence = client.user.setActivity(activityOptions);
if (!client.user.presence.equals(updatedPresence)) {
	throw new Error('User presence did not update correctly.');
}

But if, for example, the internet connection is severed, this code will still succeed, even if the actual user activity on Discord could not be updated.

This is how I know that client.user.presence does not fetch the user presence from Discord - it is simply set to the last presence set with .setPresence()/.setActivity(), even if that update fails.

Ideal solution or implementation

There are two possible solutions I would like to request:

• Have client.user.presence actually fetch the current presence from Discord, or add a specific client.user.getPresence() method
• Have client.user.setPresence() and .setActivity() actually throw an error if the API request fails

From my perspective, the second option seems like it should be the expectation (but I'm not familiar with the internal workings of d.js, so correct me if I'm wrong).

I don't know if this is possible with the Discord API. I've looked at the docs but couldn't find the answer. So if it's not possible, please let me know and close this issue.

Alternative solutions or implementations

No response

Other context

No response

[Qjuh]

You are correct in that it sets the presence without checking if the gateway call to set the presence succeeded. The reason for this is because there’s no way to check it did. It‘s not a REST call that has a response. It‘s also not issuing a websocket receive event (unless you have GuildPresences intent). And if it didn’t go through the only reason could be it was because the websocket itself was hung up or reconnecting. In both cases the payload to set the presence will remain in the queue until connected again and then it will change.

about that „bug“ in discord-api (which was closed because it really isn’t a bug): you don’t need to periodically reset the presence if you passed it in the identify call (which djs allows you to do by passing presence: {…} in the Client constructor).

[JstnMcBrd]

about that „bug“ in discord-api (which was closed because it really isn’t a bug): you don’t need to periodically reset the presence if you passed it in the identify call (which djs allows you to do by passing presence: {…} in the Client constructor).

Oh, I had not heard about that solution to the activity-disappearing issue. In the issue thread (here), it sounded like it was just a longstanding bug in Discord's backend that wipes bot activities whenever they deploy code.

Everyone else in that thread seems to be unaware of that solution. Would you mind posting it there so it can be more widely known? I think they'd really appreciate it - people have been complaining about the bug for 5 years.

[JstnMcBrd]

You are correct in that it sets the presence without checking if the gateway call to set the presence succeeded. The reason for this is because there’s no way to check it did. It‘s not a REST call that has a response. It‘s also not issuing a websocket receive event (unless you have GuildPresences intent). And if it didn’t go through the only reason could be it was because the websocket itself was hung up or reconnecting. In both cases the payload to set the presence will remain in the queue until connected again and then it will change.

Okay, that's understandable. If there's no response, then you can't guarantee the API call succeeded.

But what about adding a way to directly fetch the user's presence? If that's part of the Discord API, it would be good to add to d.js. My example use case isn't applicable, but some users might appreciate a way to directly fetch the real-time value of the presence, rather than rely on the eventually-consistent nature of the websocket queue.

Of course, if that's not possible with the Discord API, please disregard.

[monbrey]

But what about adding a way to directly fetch the user's presence? If that's part of the Discord API, it would be good to add to d.js. My example use case isn't applicable, but some users might appreciate a way to directly fetch the real-time value of the presence, rather than rely on the eventually-consistent nature of the websocket queue.

Of course, if that's not possible with the Discord API, please disregard.

Presences aren't defined on the User object, they're a property of GuildMember made available by the GuildPresences intent. Fetching your bot's GuildMember (or accessing guild.members.me) with presences enabled should provide this information.

[JstnMcBrd]

Presences aren't defined on the User object, they're a property of GuildMember made available by the GuildPresences intent. Fetching your bot's GuildMember (or accessing guild.members.me) with presences enabled should provide this information.

Okay! Is there no way to do it outside the context of Guilds? It's understandable that it would be limited to Guilds for other users (GuildMember), but what about for the ClientUser, where the presence should be independent of Guilds?

Considering it seems like my feature requests are either A) not possible, or B) already included, I think I'll close the issue after these questions. Thank you!

[almostSouji]

Presences are inherently guild-based data, so they can just be retrieved within a guild context; this is a discord API limitation.
As for the sending of presences, Qjuh covered that above.

[JstnMcBrd]

Thank you for the explanations!