I stumbled upon an odd Ruby on Rails bug this week. It was difficult to track down because it was a bug that only affected some users some of the time. Out of every 100 users: 50 would have no problems, 42 would have problems 2% of the time, 8 would have problems 8% of the time. Making it more difficult to pinpoint—during 92% of the year none of the users experienced any problems at all! Let me demonstrate the problem and explain how to solve it.

Let’s say we have a form for a user to fill out. On that form, we want the user to provide a date, but we don’t care about the day of the month; we just want the month and year. We might be asking for their birth month and year or how long they’ve been using our product. The most common example would be asking for a credit card expiration date.

Something like this:

I’m using the date_select helper method to output the date form field. It’s handy because it draws directly on a @payment object and outputs all the necessary pull-down menus with the values of @payment.card_expire already selected. I’ve passed it a few options so that it will display a month select that uses numbers, skip the day select, and display a year select from 2007-2012.

Understanding the date_select Helper

Let’s look at how this form helper works… In order to automatically group and match up the date parameters when the form is submitted, Rails uses a special technique. We already know that the entire form is submitted as an array (payment[]) and each of the fields are named inside that array (payment[:card_expire]). Like many Rails forms, that allows us access the form parameters using params[:payment] and params[:payment][:card_expire]. But the date parameters are further divided and their order will be important in rebuilding the date. Therefore, Rails names our date select fields by appending a number and a single-letter (donoting the type, ‘i’ is for ‘integer’) inside parentheses. So the month select gets the name payment[card_expire(2i)] and the year select gets the name payment[card_expire(1i)]. If we had a day field, it would be named with “3i”.

When the form is submitted, if we mass assign the parameters while instantiating an object, like this:

…then Rails will notice that some parameters have parentheses in their name and will try to reassemble them into a date before assigning the value. The parameter “reassembling” isn’t just for dates though. That’s a good thing—it is code that can reassemble lots of “multi-parameter assignments” for us. But that means when it tries to build a date, it’s going to need to know what parameter we want to use for the day of the month. It doesn’t have a default, we have to pass a value in. If we don’t, we’ll get a “MultiparameterAssignmentErrors” because the date it tries to build will be invalid. (And it won’t help when debugging that that error type doesn’t make it very clear what went wrong.)

Because Rails is always looking out for us, it saves us from having to remember to add the date value in by hand. If you look at the HTML source for the form above, you’ll see this:

Notice that even though the date was supposed to be “discarded”, Rails “helpfully” includes it as a hidden field, payment[card_expire(3i)]. You can’t even suppress the output of that hidden field because Rails “knows” that it’s likely going to need it once the form is submitted. In fact, it will create hidden fields for any field in the date that you don’t output but that it thinks it will need later. At first, that seems helpful enough.

The Rub

Here’s the problem: it includes today’s date for the value of the hidden field. 92% of the year, that works perfectly. But what if today’s date is July 31, 2007 and our user sets the expiration date selections to be “09/2007″. The hidden field will have a value of “31″, MultiparameterAssignment will try to build a date out of “09/31/2007″, the user will get a show-stopping error and we’ll get a cryptic error in our log file. Of course if today’s date is July 31, 2007 and the customer enters and expiration of “10/2007″ then they won’t get an error. The worst case is when a customer has a credit card that expires in February, then 29 days each year they will have problems. It’s a bug that’s hard to track down, because if you spot the error in your log file on the following day, you may not be able to repeat the error!

The Solution

This bug exists in Rails up to the current release, version 1.2.3. This bug has already been fixed in Edge Rails and will be available to everyone in the next release. It still uses a hidden field but, instead of using today’s date, it will default to 1. A much better solution!

Until you are using a patched version of Rails, you can just override the value of params[:payment]['card_expire(3i)'] with your own.

Like this:

Or like this:

This entry was posted on Wednesday, August 1st, 2007 at 10:05 am and is filed under Ruby on Rails, Tutorials. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.