[CORE-206] Query failing to time out into processing queue Created: 12/Feb/16 Updated: 17/Oct/16 Resolved: 21/Sep/16 |
|
Status: | Closed |
Project: | i2b2 Core Software |
Component/s: | CRC Cell |
Affects Version/s: | 1.7.07 |
Fix Version/s: | 1.7.08 |
Type: | Bug | Priority: | Major |
Reporter: | Joseph Applegate | Assignee: | Janice Donahoe |
Resolution: | Fixed | Votes: | 2 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Affects View/s: |
Query Tool
|
i2b2 Feature/s: |
Queries, Queries - Large
|
i2b2 Sponsored Project/s: |
i2b2 Core
|
Participant/s: |
Description |
Long queries are not timing out properly with an alert box. They just apparently go on forever in the client, although they've really moved to processing in the back-end. Following the suggestion in this thread https://groups.google.com/forum/#!topic/i2b2-install-help/mzSI5hgeiO4 I was able to find the error:
js-i2b2/cells/CRC/CRC_ctrlr_QryStatus.js:570 Uncaught TypeError: Cannot read property 'firstChild' of undefined The end_date is null. I worked around it by changing the line to: var endDateResult = i2b2.h.XPath(temp, 'descendant-or-self::end_date'); if(endDateResult && endDateResult.length > 0) self.QI.end_date = endDateResult[0].firstChild.nodeValue; //Query Report BG I would submit a patch but don't know enough about i2b2 to know if that's just a hack, if a null end_date is unexpected, or if you would rather apply a better check to all the query properties in that function. |
Comments |
Comment by Janice Donahoe [ 17/Oct/16 ] |
This change was included in version 1.7.08, which was released on 10/07/2016. |