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

Fix to continue with iteration when no access token is present #17

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

railsmechanic
Copy link

When a user has no access token, the script raises an error and stops. When re-running the script, it always stops at the same point. This fix skips users without or with an empty access token and continues the execution

Copy link
Collaborator

@HerHde HerHde left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, @railsmechanic!

  • Do you know how it comes that some users don't have an access token? Are we talking about a specific use case in a re-run or a bug causing it?
  • I'd like to add a log entry on skip before merging this

Otherwise this looks good to me

@railsmechanic
Copy link
Author

  • Do you know how it comes that some users don't have an access token? Are we talking about a specific use case in a re-run or a bug causing it?

To be honest, I can't give you a definite answer. I executed the script and at the point "Setting direct chats to be displayed as such for each user" the execution aborted with an error (faulty/missing) access token. Then I checked the SQLite database and noticed that there was no access token (NULL) for a number of users. Therefore I changed the script like in the PR to be able to continue with the execution.

  • I'd like to add a log entry on skip before merging this

I'll adjust the PR to log, when a user is skipped.

@HerHde
Copy link
Collaborator

HerHde commented Jul 11, 2024

I guess it might be better to wait for more insight what causes that situation. If anyone else reads this, how did this happen? 😅

@HerHde
Copy link
Collaborator

HerHde commented Jul 16, 2024

Another question that comes to my mind:
The SQLite db is not normalised, therefore the IdMappings can have different types. Are you sure that any entry of the user type had a nullish token?

Maybe you could try with this:
select * from id_mapping where type = 0 and accessToken is NULL;

Thanks a lot.

@railsmechanic
Copy link
Author

The SQLite db is not normalised, therefore the IdMappings can have different types. Are you sure that any entry of the user type had a nullish token?

I will test it again and report how it behaves now. Many thanks for your efforts. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants