Fallback to site DB on searches by username

[mbaruh]

We sometimes need to query user data such as the user or infractions embed, when all we have is the username.

Since the site DB stores user ID's and usernames, and already has an endpoint to retrieve stored data based on username, we can use that in case the user is not in the guild and we try to query by their username. That way we can get the user's ID and query based on it as usual.

This can be implemented by improving the FetchedUser converter to handle cases where the given arguement doesn't represent an integer.

[MarkKoz]

@mbaruh The fetch API call already provides a User object with a name attribute filled in. Did you mean "nickname" rather than "username"?

[MarkKoz]

Also, can you provide an example of a situation in which you are only able to identify someone by their user/nickname? If it's coming from bot output, then appending the ID to those outputs or using mentions can be considered.

[Akarys42]

Also, can you provide an example of a situation in which you are only able to identify someone by their user/nickname? If it's coming from bot output, then appending the ID to those outputs or using mentions can be considered.

Most of the time it is in a ModMail thread, where a user would report a user who left in the meantime for instance.

[mbaruh]

@MarkKoz the UserConverter relies on the cache, which is usually not enough. Whenever we try look someone up by name#discrim when they've left the guild we get an error.

[MarkKoz]

@MarkKoz the UserConverter relies on the cache, which is usually not enough. Whenever we try look someone up by name#discrim when they've left the guild we get an error.

It doesn't anymore; see #1742

[mbaruh]

I see. If after merging it's resolved I'll close the issue then.

[TizzySaurus]

@MarkKoz the UserConverter relies on the cache, which is usually not enough. Whenever we try look someone up by name#discrim when they've left the guild we get an error.

From my understanding this will still be the case. The UserConverter only doesn't rely on cache when the user id is passed. If you want name#discrim support for non-cached users who aren't in the server then the UserConverter won't provide this (again, if I'm correctly understanding & remembering everything).

[mbaruh]

From my testing the converters PR does not achieve the desired behavior described here.

[TizzySaurus]

How exactly are we planning on implementing this functionality?

My thoughts currently is that rather than adding another converter, we'd allow the passed user to be a str and in the case it is a string, we call some utility function which will query the database . This utility function would return None/raise an error when the username isn't found and return the wanted data (e.g. infractions) when the username is found.

[MarkKoz]

Why should it not just be a converter? What advantage is there to invoking it manually?

[TizzySaurus]

Making it a converter brings other complications, like what would it return?

I suppose we'd want the converter to return a custom datatype instance which has all of the user data obtainable from the database?

I'm struggling to envisage how exactly this would work.

[mbaruh]

Making it a converter brings other complications, like what would it return?

I suppose we'd want the converter to return a custom datatype instance which has all of the user data obtainable from the database?

I'm struggling to envisage how exactly this would work.

The way it would work is that it would try to find the username and discrim in the database, and if it's there fetch the ID. Once you have the ID you can use the discord API as usual.

It can then just return a User object.

[TizzySaurus]

Right, but what about when it's a deleted account? The user id will return from the database but converting to a User object will fail (would have to have a fallback of discord.Object, meaning the converter would have two possible return types)

[mbaruh]

It should just fail to convert in that case.