View Issue Details

IDProjectCategoryView StatusLast Update
0020727mantisbttimelinepublic2016-06-12 00:42
ReporterdregadAssigned Todregad 
PriorityurgentSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target Version1.3.0-rc.2Fixed in Version1.3.0-rc.2 
Summary0020727: Error 1100 (issue not found) in my_view_page
Description

Today I pushed a commit to Github that had a reference to an invalid bug number due to a typo (#20275 instead of 0020725).

Immediately after that, my_view_page started erroring out:
APPLICATION ERROR 1100 - Issue 20275 not found.

I repeated the error with $g_detailed_errors = ON (see attached) and it appears the error is triggered when timeline_api.php calls history_get_event_from_row() at line 48.

Additional Information

Issue is marked as private because I attach a dump with $g_detailed_errors = ON.

TagsNo tags attached.

Activities

dregad

dregad

2016-03-21 11:01

developer  

20160321-app_error_1100-Issue_20275_not_found.html (48,601 bytes)
dregad

dregad

2016-03-21 11:02

developer   ~0052818

Reminder sent to: atrol, dregad, vboctor

Hi guys, this issue is urgent as it's crashing the My View page at http://mantisbt.org/bugs

I unfortunately don't have time to look into the root cause right now, maybe one of you guys can do it. Otherwise I'll do it tonight.

dregad

dregad

2016-03-21 11:06

developer   ~0052819

One more thing, I just ran the SQL statement in the ADORecordset

mysql> SELECT * FROM mantis_bug_history_table WHERE date_modified >= 1457966655 AND date_modified < 1458571455 ORDER BY date_modified DESC,id D
ESC;
+--------+---------+--------+---------------------------+--------------------------+--------------------------+------+---------------+
| id     | user_id | bug_id | field_name                | old_value                | new_value                | type | date_modified |
+--------+---------+--------+---------------------------+--------------------------+--------------------------+------+---------------+
...
| 199187 |   17784 |  20275 | Source_changeset_attached |                          | MantisBT master 41975647 |  100 |    1458566875 |
...

I think we possibly have 2 bugs here

  1. Source Integration should not attach a changeset / create a history entry for a non-existant bug
  2. The History API should not choke on an invalid bug ID
vboctor

vboctor

2016-03-21 11:40

manager   ~0052821

I'm not sure about where exactly we are failing in the my view page. But by design the history APIs don't expect to be given a bug # that doesn't exist. So I'm not sure I would consider this a bug. We could change that behavior, or per the other places, make sure we are passing in a valid bug id.

vboctor

vboctor

2016-03-21 11:51

manager   ~0052822

I've applied a temporary fix to our live instance to check the bug id in history_get_event_from_row() before doing work on it. That is easy to checkin, but the question is whether we want to increase the number of queries by doing such check per bug. I would rather just fix the cause of the data error which is the Source Integration plugin.

dregad

dregad

2016-03-21 12:02

developer   ~0052823

Thanks for fixing it Victor. I assume you added a bug_exists() check ? If that's the case it wouldn't increase the number of queries (use of the bug cache), so it's probably not a bad thing to keep.

That being said, I fully agree that we should look into the root cause of the error, i.e. the Source Integration plugin if that's what it is, and fix that.

dregad

dregad

2016-03-22 05:41

developer   ~0052826

Source Integration plugin issue: https://github.com/mantisbt-plugins/source-integration/issues/157

dregad

dregad

2016-03-22 08:25

developer   ~0052838

For data cleanup purposes:

  • Identifying all Changesets referencing non-existing issues:

SELECT sb.*
FROM mantis_plugin_Source_bug_table sb
LEFT JOIN mantis_bug_table b ON b.id = sb.bug_id
WHERE b.id IS NULL
ORDER BY 2, 1

  • Identifying all orphaned History records:

SELECT h.*
FROM mantis_bug_history_table h
LEFT JOIN mantis_bug_table b ON b.id = h.bug_id
WHERE b.id IS NULL
ORDER BY 3,2,1

dregad

dregad

2016-05-23 19:57

developer   ~0053208

I just fixed the Source integration plugin and updated it on our tracker.

Will do the data cleanup later; once done, @vboctor's temporary fix can be removed and this issue resolved.

dregad

dregad

2016-05-24 06:25

developer   ~0053210

Last edited: 2016-05-24 06:39

View 2 revisions

@vboctor some thoughts on data cleanup before I go ahead:

  • There are 19 changesets referencing non-existing issues (mantis_plugin_Source_bug_table) that can be safely deleted.
  • These correspond to 19 matching history records, which can also be deleted without foreseeable risk.
  • In addition, there are 48 additional orphaned history records not originating from the source integration plugin. They have the following characteristics
    • bug_id = 0 (not sure how this could have happened)
    • this is all fairly old data (2007..2009)
    • 8 have type = 9 (FILE_ADDED)
    • the remaining 40 are of type 0 (NORMAL_TYPE), changes to 'status' field
    • these trigger the same error as described above (e.g. https://www.mantisbt.org/bugs/my_view_page.php?days=2500 - that's period 2009-07-13 .. 2009-07-20)

I am not sure how these records were created in the first place, maybe they are leftovers from old bugs ? Anyway, IMO they can be deleted as well. Let me know your thoughts on that.

To be on the safe side and avoid future occurrences of this error, I would recommend to implement a fix like one you put in place per 0020727:0052822 (it is no longer on the tracker's repository).

I believe the overhead of the extra bug_exists() call is negligible, as it is highly likely that the bug will cached already, and we need to read the bug data in any case for subsequent bug_get_field() or access_has_bug_level() calls.

dregad

dregad

2016-05-24 06:40

developer   ~0053211

https://github.com/mantisbt/mantisbt/pull/780

Related Changesets

MantisBT: master ef2628e1

2016-05-24 06:27:45

dregad

Details Diff
Let Timeline handle non-existing bugs

If an history entry refers to a bug that does not exist in the database,
history_get_event_from_row() throws application error 1100.

Even though it is not a normal situation to find orphan records in the
history table, the overhead of verifying a bug's existence at the
beginning of the loop is negligible, so it doesn't hurt to add the extra
bug_exists() check.

Fixes 0020727
mod - core/history_api.php Diff File

Issue History

Date Modified Username Field Change
2016-03-21 11:01 dregad New Issue
2016-03-21 11:01 dregad File Added: 20160321-app_error_1100-Issue_20275_not_found.html
2016-03-21 11:02 dregad Note Added: 0052818
2016-03-21 11:06 dregad Note Added: 0052819
2016-03-21 11:40 vboctor Note Added: 0052821
2016-03-21 11:51 vboctor Note Added: 0052822
2016-03-21 12:02 dregad Note Added: 0052823
2016-03-21 12:16 vboctor Assigned To => dregad
2016-03-21 12:16 vboctor Status new => assigned
2016-03-22 05:41 dregad Note Added: 0052826
2016-03-22 08:25 dregad Note Added: 0052838
2016-05-23 19:57 dregad Note Added: 0053208
2016-05-24 06:25 dregad Note Added: 0053210
2016-05-24 06:39 dregad Note Edited: 0053210 View Revisions
2016-05-24 06:40 dregad Note Added: 0053211
2016-05-29 06:36 dregad Changeset attached => MantisBT master ef2628e1
2016-05-29 06:36 dregad Status assigned => resolved
2016-05-29 06:36 dregad Resolution open => fixed
2016-05-29 06:36 dregad Fixed in Version => 1.3.0-rc.2
2016-05-29 06:36 dregad View Status private => public
2016-06-12 00:42 vboctor Status resolved => closed