#9 Ninth Week [Bugs can be scary!]

I've encountered a couple of unexpected bugs this week with the GitHub API and spent majority of the time trying to fix them.

TL;DR

• Fix bugs related to insufficient permissions to fetch data from GitHub API.
• Rewrite background validator task to run less frequently and after long intervals.
• Support for queues to trigger a background validation check everytime a room condition is edited or a new user is added.

Related PRs

• #49 - Patreon OAuth
  
• #56 - Trigger validation checks when a new condition is added

Long version

I had a call with my mentors this week to discuss about the project's overall progress and I got the chance to show a working example for the project. 

While I was presenting I noticed a couple of unexpected bugs with the background validator.

The "Bug"

In my previous posts, I talked about how the background validator works in general but I didn't go in detail on how the data from third party accounts is fetched and how they are compared with the conditions saved in the room account data. 

Let's take an example and go over it now.

Consider that we are dealing with the repository conditions for a GitHub repository under an owner (user/org) saved in the room account data and would like to validate a particular user's room membership.

We start by fetching the GitHub access token for the current user being validated and try to fetch data related to repository permissions. But the problem comes when the user doesn't have push access for the repository. In that case, we end up with the error "Must have push access to view collaborator permission."

So, what do we do? 
We will have to handle it differently based on the owner. If the owner is a user, we can just use the ir access token and get the relevant permissions. 

You might be wondering "how can we say for sure that we'll have the access token of this user?". Well, only the owner has the ability to add repository conditions that they own for a room and if a repository condition is saved under a room then obviously the user must've registered with our application.

What if the owner is an organisation instead of a user? 

This is where it gets tricky. We will have to keep track of the last user who has added/edited the room condition by saving their GitHub username along with the room conditions data.

This way we can always ensure that we never run into "Must have push access to view collaborator permission" problem.

How do I make it less frequent?

Until now, the background validator gets triggered every 10 seconds. This is too frequent, unnecessary and can be very resource consuming.

So, my mentor suggested to run it every 1 hour or so and make it less frequent. 

But a user/room admin will have to wait for an hour until the updated changes can take effect every time they edit room conditions. 

To handle this problem, we made use of asyncio-queue to process the recently edited room conditions in a FIFO manner.