bug: empty username picked when first name and last name have more than 10 chars

[nekomeowww]

fix pkg/tgbot/utils.go

[rafiramadhana]

@nekomeowww Is this fix related to FullNameFromFirstAndLastName?

insights-bot/pkg/bots/tgbot/utils.go

Line 64 in 53ddb31

func FullNameFromFirstAndLastName(firstName, lastName string) string {

In addition, would you mind to provide an example of input (i.e. the first name and last name with >10 chars) related to this case?

Lastly, what are the expectation? Trimming the output?

Thanks!

[nekomeowww]

Hey, welcome to this repo and contribute!

@nekomeowww Is this fix related to FullNameFromFirstAndLastName?

insights-bot/pkg/bots/tgbot/utils.go

Line 64 in 53ddb31

func FullNameFromFirstAndLastName(firstName, lastName string) string {

I checked the source code and find out I miss stated the package that needs to be fixed. The correct one should be:

insights-bot/internal/models/chathistories/chat_histories.go

Line 159 in 53ddb31

func formatFullNameAndUsername(fullName, username string) string {

In addition, would you mind to provide an example of input (i.e. the first name and last name with >10 chars) related to this case?

The related edge cases should be the following:

Case One

Over 10 chars of first_name but empty last name and empty username.

{
  "first_name": "blah blah | SomeSubName :> | 😄",
  "last_name": "",
  "username": ""
}

Case Two

Over 10 chars of first_name but with only empty last name.

{
  "first_name": "blah blah | SomeSubName :> | 😄",
  "last_name": "",
  "username": "example_username"
}

This function is used to match the very long name I have seen in Telegram initially, some of the people would use the blah blah | SomeSubName :> | 😄 as their first name (or with last name combined), usually they would have a shorter username that would save more tokens (which is the case 2).
However, I encountered one people with simple Example Name first name but without username being set, so the function would simple return a non-exist username and break the context.

Lastly, what are the expectation? Trimming the output?

The answer to this question is: probably yes?

You might have to come up a idea about how to trim the very long first name in case 1 while still covering case 2.

[rafiramadhana]

@nekomeowww what if full name (first name + last name) is over 10 chars and username is longer than full name?

something like:

first_name: aaaaa
last_name: bbbbbc
username: aaaaabbbbbccccc

are we still returning the username?

usually they would have a shorter username that would save more tokens

because it looks like you prefer to return shorter string here

[nekomeowww]

@nekomeowww what if full name (first name + last name) is over 10 chars and username is longer than full name?

something like:

first_name: aaaaa
last_name: bbbbbc
username: aaaaabbbbbccccc

are we still returning the username?

usually they would have a shorter username that would save more tokens

because it looks like you prefer to return shorter string here

Yes, it is better to have the less one. Therefore it is not strictly to say we have to return username or fullname, it is ok to return the shorter one directly. If the returned one is still to long (such as 20 runes), we might have to trim the string off.

[rafiramadhana]

Therefore it is not strictly to say we have to return username or fullname

OK. I think it is clear enough.

[rafiramadhana]

@nekomeowww Would it be OK if we remove spaces from the fullname?

"my name has spaces" -> "mynamehasspaces"

[nekomeowww]

@nekomeowww Would it be OK if we remove spaces from the fullname?

"my name has spaces" -> "mynamehasspaces"

If you are talking about the space between first name and last name, pkg/bots/tgbot.FullNameFromFirstAndLastName should have done the jobs for you. If you are talking about the spaces within the full name, I think it is not ok, because the full name will eventually be displayed in messages.

[nekomeowww]

How about just return the full name if it exceeded the 10 char limits and username is empty for now?

There are planning features (#47, #48) to process the user info more elegantly. We can discover and come up with more better ideas to improve the processing logics for those issues.

[rafiramadhana]

@nekomeowww Sounds good to me. We can implement it that way.