-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incomplete presence info and guild members #137
Comments
Here is another thing that I am more sure is a bug, because I see the info in the HTTP request:
Perhaps something similar to the last fix? |
Thankfully, retrying I am getting a memory leak when I allocate snowflakes for retrying guild members:
I assumed since |
I don't think it's a bug.. the payload shown there is for when a |
It's actually for Another thing that seems to be happening is when I retry the presence requests to try to get them all, the gateway will close:
This seems to be the last thing in
Sometimes I'm able to get a few retries in when doing this. The most problematic aspect about the reconnect is mainly that my retires stop, so I never end up getting all the presences. |
Indeed, Can you solve this issue of yours without calloc'ing? Once the function is called it will immediately serialize the struct into a JSON, so concord doesn't need to keep a dynamic pointer around.. Alternatively, you could just do this: missed = calloc(1, sizeof(*missed));
struct discord_request_guild_members params = {
.guild_id = u->guild_id,
.query = "", /* Empty string to return all members */
.limit = presencefails, /* All members */
.user_ids = missed, /* Filter to only users whose status we failed to get the first time */
.presences = true, /* Include presences */
};
discord_request_guild_members(client, ¶ms);
free(missed); // there we go |
Okay, if it's done being used when it returns, then that's fine, I'll actually make it stack-allocated then, and just free the array, since that's what I was going to do initially before I presumed that wouldn't work. So I don't think the API needs to be changed, thanks for the clarification. I think with that, I've been able to figure out or work around most things. I can work around channel members using permissions as a proxy, I can retry the presence requests, and I think the only things I'm stuck on are the guild owner being 0 (perhaps |
Honestly, never got that from Discord before. I'll see if I can replicate your issue when I find some time. |
Okay, so the decoding error is actually on their end, and now I see why: I removed some of the details in the middle, but this is from the log:
If I limit my retry requests to 25 maximum per retry, instead of, say, 58, as in the example above, then this issue doesn't happen, so it smells a lot like buffer truncation somewhere to me. |
It is actually a concord issue, atm we are doing a very naive approach of using fixed-sized buffers for storing our JSONs, hence the truncation you're experiencing... We will be changing all those cases to dynamically-sized buffers (in a recyclable manner), which will certainly fix this issue you're experiencing! Could you please open another issue for this? Thank you so much for spotting all these bugs on such short notice! |
Hey, I went ahead and enlarged that buffer a bit; recompile on the |
@HackerSmacker Thanks, did you mean to change the buffer size in Increasing the buffer size in discord_gateway_send_identify didn't make any difference, but increasing from 1024 to 4096 there made it work for me. It was failing between 40 and 45 members for me so I think 2056 would have been sufficient for my use case as well. But in a larger guild, 2056 would probably be insufficient too. |
I went ahead and did both, but, in theory, the buffer size that holds that identify-payload probably needs to be dynamically generated somewhere, to avoid running out of room on account of that exact issue. |
Thanks! Another strange thing I've noticed... my retries aren't actually working the way I thought they were. My algorithm is for each chunk of members we get, keep track of all the members for whom we fail to get presence data. We'll then make another request just for those members, and repeat over and over until we have all presences, or we make a request that returns no new presence data (so as not to infinite loop on this). Looking at Is it possible that the request is invalid, particularly I'll go ahead and open a new issue now for the buffer size. |
This is 100% speculation, but just an idea after reading the documentation here: https://ptb.discord.com/developers/docs/topics/gateway-events#request-guild-members It says the guild_id and user_ids should be snowflakes. Right now, they are both surrounded by strings. It seems to work for guild ID anyways, but I wonder if removing the quotes around the user_ids would fix this. Honestly, I have no idea though, just a thought. I don't know if snowflakes are supposed to be surrounded in quotes in JSON or if they can be lone like integers. This happens even in the simplest case of limiting the query to a single user (and only providing one for |
They are actually supposed to be wrapped in quotes, and this is due to a Javascript limitation, their This is detailed here, concord actually receives snowflakes as strings and then we perform a conversion to |
Opening a new ticket for this, there was some initial discussion of this on #135
I'm now able to get presence data, but it seems
presence->size
can be smaller thanmembers->size
in the event.From looking at
http.log
, it seems the JSON array really only is that large, so perhaps this is an API issue:discord/discord-api-docs#666
discord/discord-api-docs@12b414e
Since this was initially "undocumented", I wonder whether this is also an "undocumented limitation". It's also not consistent, now when I last tried it, I only got 28 presences, instead of 34 like before (still far under 77). I can confirm there's only one chunk received, so it's not as if the presences are getting split.
One workaround may be to retry any users we didn't get presence data in another request, filtered to such user(s), although it would be nice if the API response worked properly in the first place... oh well. It's very possible there's not much that can be done in this case.
Returning to the other thing I had mentioned, this seems like something that may not be quite right:
(It's hard to parse the official APIs, but this suggests that accessing recipients is the right way to get channel members: https://stackoverflow.com/questions/50840580/how-to-retrieve-a-list-of-discord-users-in-a-channel)
I thought perhaps maybe member is not set by default (like how the other API requires
.presences = true
in order to get presence data, but there doesn't seem to be any such boolean flag, so I would assume members should always be returned. Some of the other data is set, but this one is NULL.This is from the HTTP logs:
Edit: I realize I should be using
recipients
rather thanmembers
, but both are actually NULL.Looking at
http.log
, unfortunately this data doesn't seem to be present, either, which is incongruent with their API documentation to me.So I'm not sure if either of these is very actionable, but I know there was a fix for something, so I guess that can be linked against this issue instead now.
The text was updated successfully, but these errors were encountered: