PrasandP / acra-reporter

Automatically exported from code.google.com/p/acra-reporter
0 stars 0 forks source link

Reports not being marked as Fixed or Looked At #13

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Open any NEW error report
2. Tick Fixed check mark (or looked at)
3. Reload the page, it's still under NEW and Fixed check mark is unchecked

What is the expected output? What do you see instead?
Once report is marked as Fixed, it should not be under NEW

What version of the product are you using? On what operating system?
Latest from trunk

Please provide any additional information below.

Original issue reported on code.google.com by sergei.l...@gmail.com on 18 Jun 2013 at 6:03

GoogleCodeExporter commented 8 years ago
This works for me, i have noticed a similar problem before when users had maxed 
out the write quota, so saving the state of the check box didn't work..

Original comment by mat...@winters.org.nz on 30 Jul 2013 at 10:54

GoogleCodeExporter commented 8 years ago
Thanks for reply. I did not do any configuration changes in app engine console. 
Should I?

Original comment by sergei.l...@gmail.com on 31 Jul 2013 at 5:31

GoogleCodeExporter commented 8 years ago
same here:
I have this problem for some of reports (not all, but seems it happens when I 
have multiple reports with close/same timestamp - the report doesn't get 
changed state - it always remains 'new' (reappears when pressed 'refresh' 
button.

Note: I've installed own copy of trunk version, with config:
 appUserMode = UserMode.umMultipleSameApps;

Original comment by a66211...@gmail.com on 12 Jul 2014 at 9:41

GoogleCodeExporter commented 8 years ago
ok, today I did a quick analysis :-)

The issue is caused by multiple duplicate bugreports entries.

1. Cause of duplicate entries:
When client reports some bugreport (with same 'REPORT_ID') twice or more times 
at once (didn't analysed a reason, something wrong on client side), all reports 
are coming to server side simultaneously. As result the 
ACRAReportHandler.doPost() is invoked simultaneously in some threads  - current 
implementation of the duplicates-check fails because of lack of atomic 
check/insertion (currently it works perfectly for delayed simultaneous posts, 
but fails when posting same record in two parallel threads). 
As result it generates in database multiple entries with different 'id' and 
same 'REPORT_ID'.
The quick solution is in attached ACRAReportHandler.java

2. When administrator tries to operate over duplicate entries created on step 1:
Another problem: when some duplicate entries exist in database, all actions in 
the ACRA admin console are performed on first entry filtered by 'REPORT_ID'. So 
whenever admin marks bug as 'fixed', or 'looked at' - all changes go to first 
entry with given 'REPORT_ID', and other entries remain untouched. In principle 
only workaround is: delete duplicate bug-report.
Here is a quick solution (on all operation, now it iterates over all 
duplicates): see attached RemoteDataServiceImpl.java

3. When administrator operates over duplicated records, the package 
total-counters are incremented/decremented uncontrollably, as result it drives 
to negative values, or values much more than total reported entries (I had 700 
total reports, with 1400 deleted entries, and negative value on 'Looked at'). 
Theoretically this issue to be fixed with direct database modification, but 
unfortunately AppEngine datastore viewer doesn't allow view/modify blob data.
To fix wrong numbers I've applied following quick solution: see attached 
Counts.java

Theoretically it's enough to apply only first solution (on ACRAReportHandler) - 
should work perfectly on new applications.
When some existing application(s) already contain duplicate reports, then it's 
also necessary to apply second (RemoteDataServiceImpl)
When some existing application also contains weird counters, or 'new' counter 
is always = 0 (that's because of negative value), then it's also necessary to 
apply third solution (Counts) for short time or permanently - doesn't matter.

Original comment by a66211...@gmail.com on 3 Aug 2014 at 8:22

Attachments: