Bugs in DrProject
DrProject 2.0 has been in use for almost a month now, and we’ve tripped over some ugly bugs. The worst one isn’t our fault: we’ve discovered that Firefox sometimes sends two identical HTTP requests to the server when a link or button is clicked once, so that two identical transactions are launched just milliseconds apart. We’re going to deal with it (for now) by simply ignoring the database exception thrown by the second transaction, but apparently we’re not the first to trip over this. (Thanks to David Humphrey for the pointers.) Shawn K. tells me the same thing has been seen in IE; how do other people cope with it?
There are also problems with the admin interface—the portal for CSC301 had to be rebuilt yesterday because of one of them. It all reminds me of something my boss at BNR told me in 1985: “When there’s one bug in a release, it’s the developer’s fault. When there are lots, it’s the manager’s.” I should have insisted that we switch to 2.0 for internal use early in August, before going on vacation, so that we would trip over these things before students were exposed to them. *sigh*
On the bright side, David, Alex, and Alan the heroic sys admin are turning problems around very quickly. I hope we’ll have 2.0b ready in a couple of weeks, and 2.1 (with the snazzy new ticketing system, and a REST API) looks like it’s on track for December or January. Fingers crossed…
Greg,
There is a trick for web applications to protect the app from users that click the button twice. Maybe this trick can help you with the firefox problem as well.
Basically, when the first request occurs, your server code should obtain a token/lock. This token associates this user, with this particular page, for this session. The token should be obtained before you access the database.
When the second request occurs, since the token is already taken, the request does nothing.
This is similar to obtaining a lock when synchronizing two threads, except that in this case you sort of “drop” the second thread. Once the first request/thread is done, it relinquishes the lock and returns a response to the browser.
How can you cope… Maybe make GET requests idempotent?
(I’ve hit this as well with the web apps I’ve been writing, but it hasn’t been a real pain for me, because I just end up returning the most recent state of the server.)
(For that matter, why does querying tickets insert data into the database anyways?)
Thank you both for the suggestions. I don’t think the token idea works, because it’s the *first* transaction that has to be dropped, not the second (Firefox closes the first connection when it gets the “second” click), and we’d get into timeouts and the like server-side — DW, can you chip in? And querying tickets updates the database because we need to store the query criteria so that the previous/next links will do the right thing — DW, again, can you jump in?
@Greg: I’ve taken a look at the bugs that David Humphrey pointed us to… And unfortunatly none of them seem relevent.
@Yoni: These are the problems with using some sort of locking mechanism:
0) Because the two requests are happening so fast (within less than 1/100th of a second), there is no way to ensure that the first request in is the one to get the “lock”.
1) Firefox ignores the data sent back to the first thread, so we would actually have to wait for the SECOND thread, then send the data there.
@Blake: Just as Greg said. It’s saving a bit of session information: the tickets that the user can see, so if they click the “next ticket” link, it does the RightThing.
Are you using GET or POST here?
Two of the four “bug reports” you link to clearly define the problem as “user error” in the form of bad HTML; perhaps you need different links to support your case. The fourth one is about 5 years old, and probably no longer relevant?
In short, I can’t get a handle on the actual problem based on what I can see from here…
Update: This has been solved. See my blog post.
Glad to see that this was solved. I thought it was related to an img tag with an empty src, not to an onclick event.
@David
That’s an interesting problem. However, in my previous comment I didn’t describe the solution in full details. The complete idea is that the second request is not actually dropped. It’s kept inactive, and after the server finishes processing the first request, the output of the first response is redirected to both responses. That might solve the issue of not really knowing which is first.
@Greg
I would have responded earlier had I known that there are more comments.
Subscribe To Comments comes to mind
http://wordpress.org/extend/plugins/subscribe-to-comments/