Lillith was integrating some new tools into an existing Ruby on Rails API. The existing API allowed you to send a dry_run flag along with the request, so that you could have the service calculate its changes without applying them.

The problem was, the new tool Lillith was integrating could send, in the body of the request, {"dry_run": false}, but the service would see it as true. Consistently.

The helper method which checked for "true" parameters looked like this:

def param_true?(param_name)
  param_value = params[param_name]
  params.key?(param_name) && (!param_value || param_value.to_s.downcase == 'true')
end

The purpose of this function is to handle stringy or nil inputs gracefully. And there's one thing I can say about the function: it will always identify a true value correctly. If your false value is a string, "false", it also works. But that pesky !param_value mean that any actual boolean false value will be seen as true.

This function has been in wide use through the application. Lillith's best guess is that up to this point, no one had set the dry run flag on anything but GET requests, where everything was strings. On POST/PATCH/PUT requests, where the data was passed in the body as JSON, it got parsed into actual boolean values, and thus failed.

That's the WTF, certainly, that this function was lurking and waiting to cause this confusion. But the annoying thing in this function is that it fetches the value from the associative array, then calls params.key? to see if the key exists. That's fine, since Ruby just returns a nil if a key doesn't exist, it's just annoying. I hate to see it. This is, admittedly, more of a "me" problem, but I hate it.

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.