Closed
Bug 965345
Opened 12 years ago
Closed 12 years ago
Remove test-run query
Categories
(Tree Management Graveyard :: OrangeFactor, defect)
Tree Management Graveyard
OrangeFactor
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mcote, Unassigned)
References
Details
Attachments
(1 file)
|
16.67 KB,
patch
|
jgriffin
:
review+
|
Details | Diff | Splinter Review |
Since deploying bug 909368, when you look at the details of a bug, e.g. http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=934938&startday=2014-01-22&endday=2014-01-29&tree=trunk an error dialog pops up saying "200: OK"... which is not an error. I can't reproduce this locally.
| Assignee | ||
Comment 1•12 years ago
|
||
Doesn't seem to happen if you go directly to the link above, but it does happen if you go from another Orange Factor page via a bug [details] link. Wonder if it has something to do with aborting an on-going AJAX request. I'll file a separate bug for that.
| Assignee | ||
Comment 2•12 years ago
|
||
According to the web console and running the problematic URL through curl, the actual error is 414 Request-URI Too Large. Indeed, we're doing a call to api/testrun with an enormous URL. I have no idea why this is showing up as a 200 OK, and I still don't know why I can't reproduce it locally. It could have something to do with nginx vs the local dev server, but that doesn't explain why the error doesn't show up when loading from a file:/// URL, which should use the server on brasstacks.
I would like to figure out why the error isn't being displayed properly, but it is more important to either stop doing these queries (not sure how useful they are anymore anyway) or split them up or use a POST body or something.
| Assignee | ||
Comment 3•12 years ago
|
||
Okay seems that the server isn't actually returning a 414; rather, it's returning an error message in HTML with a 200 OK. This is causing the error callback to be invoked because dataType is set to 'json', so the parser fails when it gets the HTML error message. There is no obvious way to determine that the request failed due to a 414 aside from trying to interpret the HTML.
So I think we should just fix these too-long queries, since the 414-error problem seems to be on the server, and I don't think it's worth trying to work around on the client. Updating summary appropriately.
Summary: "200: OK" error dialog on bug details → URLs for some test-run queries are too long
| Assignee | ||
Updated•12 years ago
|
Assignee: nobody → mcote
Status: NEW → ASSIGNED
| Assignee | ||
Comment 4•12 years ago
|
||
So these queries haven't even been working for a long time, probably as a result of bug 707319. Before too long, we're moving star data to treeherder, so I don't think it's worth fixing now, if ever. We need to revisit all of Orange Factor's functionality in light of treeherder anyway. So changing this bug (again) to just removing the test-run queries.
Summary: URLs for some test-run queries are too long → Remove test-run query
| Assignee | ||
Comment 5•12 years ago
|
||
I removed the Bug Correlations view as well, which has also been broken forever.
Attachment #8370328 -
Flags: review?(jgriffin)
Updated•12 years ago
|
Attachment #8370328 -
Flags: review?(jgriffin) → review+
| Assignee | ||
Comment 6•12 years ago
|
||
Pushed and deployed.
http://hg.mozilla.org/automation/orangefactor/rev/c551161df303
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Product: Testing → Tree Management
Updated•5 years ago
|
Product: Tree Management → Tree Management Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•