We had a meeting today to make some final updates/improves to the code and go over our presentation. I updated the code that determines when the user can check-in and what defines a "day" and a "week" is. Previously, for testing purposes, we had set a day to be 20 seconds and a week to be 7*20 s = 140 seconds. This made it much easier to test the current progress code to ensure it was working as expected.
So I make the changes and run the code and...it breaks. When I take a challenge and check-in, everything is fine. But once I complete my first check-in, the "Checkin" button should then be greyed-out until 24 hours later since check-ins are permitted only once per 24 hours. However, the Checkin button is not disabled and I can click it until I finish the challenge. I ask Fernando to run his copy of the code with the seconds usage just to make sure that changing the timing didn't mess things ups. Well, the version of the code on his machine is behaving perfectly fine so I run grep in the command line to make sure that I have replaced all instances of 20.second and 140.second (rails handy way of giving a number of seconds) with 1.day and 7.day. There are no lingering occurrences so I comb through the Javascript for the current challenge progress bar to make sure that I haven't missed some code that might be messing up the timing. Nope, everything looks to be in order.
I clear out my database and take a challenge again. It works fine this time! I then login to my Facebook account and take a challenge there to make it is still working and...it breaks! The Checkin button doesn't disable after the first check-in. So it appears that this problem is caused when two or more users are all taking challenges (not necessarily the same ones) at the same time. Obviously, this is a major problem since our app should be able to handle this fine.
Matt S. and I start looking over the user's controller (which is where most of the methods that run the current progress bar are placed). We also query the database from the Rails console and notice some inconsistencies in the way the weeks and user challenges are being saved in the database. It appears that the wrong week record is being associated with the wrong user when the user is taking a challenge. We skim through the methods in the user's controller to see if we spot a place where the database is being accessed without specifying the current user id. Nothing. We can't find anything out of place so I go back to looking over the presentation.
However, the issue is still bugging me since it is a major problem with the logic of the code. I decide to go over the user's controller once again and finally find the problem. A "where" query is being run on the Weeks model but the current user id is not being passed in so there is the potential for a week record from another user to be returned for the current challenge depending on the matching results returned by the query. Once the current user id is specified in the query, I clear out the database and take challenges in both my administrator account and my Facebook account. Now the Checkin button is properly disabled no matter which account I am in.
So, problem is solved! Not quite. About an hour later, I find that it shows up again, but only after the Abandon a challenge button is pressed. After some digging around in the user challenge model (where the abandon challenge method is located), we discover that the Week records for an abandoned challenge are not being deleted and are causing issues when the next challenge is taken. After adding a line to delete all the Week records for the abandoned challenge, the code runs correctly.
We also spent some time going over the presentation and how we are going to do the demo. Next weekend, we'll meet to really hammer it out and hopefully, if we can get access to the room we will be presenting in, we can also practice in there, which would be really nice.
No comments:
Post a Comment