Skip to content
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

bug: IV is missing for open + searches #13

Open
KnorpelSenf opened this issue Apr 10, 2023 · 2 comments
Open

bug: IV is missing for open + searches #13

KnorpelSenf opened this issue Apr 10, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@KnorpelSenf
Copy link
Member

Search for ​you might be interested in +scaling.

Expected: message has IV

Actual: message has a regular link preview

@KnorpelSenf KnorpelSenf added the bug Something isn't working label Apr 10, 2023
@dcdunkan
Copy link
Member

I was able to look into the issue and find what causes this.

The links array passed to renderInputMessageContent here is empty. The IV link is pushed to the entities if the length of this array is greater than 0. Since the condition is false in this case, it results in a message without IV.

The above mentioned array is empty because the completedQueries array (here) is empty.

currentQuery has the query and completedQueries is empty. (Since currentQuery isn't undefined, the renderInputMessageContent is called with an empty links.)

The issue seems to be with the query format parsing, obviously.

currentQuery being defined depends on the length of the query.split("+") array. In this case, (query: text +FAQ) the length of split parts array is 2. So the else case below is executed. In the end, here, a length % 2 === 0 check is performed for setting currentQuery. As this condition is true for this case, currentQuery is set, but completedQueries is emptied as well.

I have to guess that initially the code was written with +closed searches+ in mind. So, if it was a closed search, the length of the split parts would be 3, the len % 2 === 0 check will not be passed and so completedQueries wouldn't be empty and this bug won't be occurring.

I don't have an actual solution to propose. So, I'm gonna leave others to that. However, as far as I tested and understood, changing the check len % 2 === 0 to len % 2 === 0 && len !== 2 can solve this issue. But I don't think it is a correct solution, even though it doesn't break other searches.

@KnorpelSenf
Copy link
Member Author

Gotta take a look at this soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants