Don't quote me
-
It's ticket cleanout week, where year-plus-old, lower priority tickets are being handed out at random to be addressed. An email notification for the following ticket caught my eye:
572: Can't save Frobinator notes with special characters
Intrigued, I decided to see what the problem was.
We need to add support for all punctuation marks on the Frobinator notes edit page. When attempting to save a note that contains a single quotation mark ('), the page generates an error. This error is caused by the quotation mark creating a syntax error in the SQL statement that saves the note.
-
-
year-plus-old, lower priority tickets
the quotation mark creating a syntax error in the SQL statement
Why did you just say two completely unrelated things?
-
@Groaner said:
year-plus-old, lower priority tickets
the quotation mark creating a syntax error in the SQL statement
Why did you just say two completely unrelated things?
Because apparently the priority of the ticket is completely unrelated to the severity of the bug.
-
Nice job, @Discourse.
-
Because apparently the priority of the ticket is completely unrelated to the severity of the bug.
And the reporter of the bug did due diligence to identify the root cause of the bug, yet not enough due diligence to actually fix it.
-
As someone in a QA role, it is my job to find bugs, often including debugging to root cause, but usually not to fix them (unless the test failure is due to a defect in the test infrastructure, and then only if it's part of the infrastructure that I'm responsible for). Often, I don't even have permission to fix it if I wanted to. I know I've filed bug reports that include descriptions like "Line 173 of file foo: == should be !=" because it's not my job to make that simple edit, even though it would have been far simpler to make the edit than wait weeks for the person whose job it was to get around to doing it.
-
Wow, being able to give advice like that to a developer who doesn't know the difference between
==
and!=
... almost makes one give a bad advice or two, just to watch the fun.(Of course, you can't really ... it'd be like the little boy who cried wolf.)
-
As someone in a QA role, it is my job to find bugs, often including debugging to root cause, but usually not to fix them (unless the test failure is due to a defect in the test infrastructure, and then only if it's part of the infrastructure that I'm responsible for). Often, I don't even have permission to fix it if I wanted to. I know I've filed bug reports that include descriptions like "Line 173 of file foo: == should be !=" because it's not my job to make that simple edit, even though it would have been far simpler to make the edit than wait weeks for the person whose job it was to get around to doing it.
The person who filed the bug was a developer, and we're still small enough that there's no red tape and begging forgiveness works. The most compelling argument for inaction is that the change might break something, and the edit form is already broken as per the bug.
A while ago, I overheard one of our QA guys observing similar behavior on another input form, and I rushed over to instruct him to treat any such failure as critical. So maybe there's some hope.
-
doesn't know the difference
I never said he didn't know the difference. It's a logic bug; they happen. Maybe the consumer changed, and now wants the inverted logic. Maybe it's just a simple typo. Maybe it's just an oversimplified an example of the sort of root-cause analysis I've occasionally put in bug reports.
-
I overheard one of our QA guys observing similar behavior on another input form, and I rushed over to instruct him to treat any such failure as critical.
Maybe not fixing it himself was a WTF, maybe not, but it's certainly secondary to the failure to properly prioritize what should have been a critical ticket. Or maybe TRWTF is that "single quote in an input form causes SQL syntax error" didn't set any alarm bells ringing in his mind. (TBH, I'm not sure it would have for me, either, before I started reading TDWTF.)
-
treat any such failure as critical
I think this is the only WTF here, a developer not knowing that this is a SQL injection vulnerability.
-
The most compelling argument for inaction is that the change might break something, and the edit form is already broken as per the bug.
HEEEERRRRREEEEEE'SSSSS Bobby!