Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reports not being marked as Fixed or Looked At #13

Open
GoogleCodeExporter opened this issue Feb 3, 2016 · 5 comments
Open

Reports not being marked as Fixed or Looked At #13

GoogleCodeExporter opened this issue Feb 3, 2016 · 5 comments

Comments

@GoogleCodeExporter
Copy link

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 [email protected] on 18 Jun 2013 at 6:03

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 30 Jul 2013 at 10:54

@GoogleCodeExporter
Copy link
Author

Thanks for reply. I did not do any configuration changes in app engine console. 
Should I?

Original comment by [email protected] on 31 Jul 2013 at 5:31

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 12 Jul 2014 at 9:41

@GoogleCodeExporter
Copy link
Author

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 [email protected] on 3 Aug 2014 at 8:22

Attachments:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
@GoogleCodeExporter and others