Bug 734194 - Failed to load change report viewing drift history
Failed to load change report viewing drift history
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.1
Unspecified Unspecified
urgent Severity high (vote)
: ---
: ---
Assigned To: John Sanda
Mike Foley
:
Depends On:
Blocks: 707225
  Show dependency treegraph
 
Reported: 2011-08-29 13:18 EDT by Mike Foley
Modified: 2012-02-07 14:30 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Failed to load change report error (46.95 KB, image/png)
2011-08-29 13:18 EDT, Mike Foley
no flags Details
client-side error (51.38 KB, image/png)
2011-08-29 13:19 EDT, Mike Foley
no flags Details
server-side log (see the end of this file) (1.07 MB, application/octet-stream)
2011-08-29 13:20 EDT, Mike Foley
no flags Details

  None (edit)
Description Mike Foley 2011-08-29 13:18:05 EDT
Created attachment 520438 [details]
Failed to load change report error

Description of problem:  Failed to load change report viewing drift history



Steps to Reproduce:
1. Drift History
2. right-click context menu, details 
 
  
Actual results:
see attached

Expected results:


Additional info:
see attached.
Comment 1 Mike Foley 2011-08-29 13:19:25 EDT
Created attachment 520439 [details]
client-side error
Comment 2 Mike Foley 2011-08-29 13:20:49 EDT
Created attachment 520441 [details]
server-side log (see the end of this file)
Comment 3 Mike Foley 2011-08-29 15:25:20 EDT
additional info:
file type = .txt
drift type = template on jboss resource
Comment 4 John Sanda 2011-08-29 21:05:30 EDT
I have managed to produce the same server side stack trace that Mike reported. I see the "Failed to load change report" error message at the top of the screen as well. I do not yet have enough information about the initial finding to know if I have reproduced the issue or something different. Here are the steps I took to generate the same exception in the server log posted in comment 2:

1) For any resource make a change that will generate drift (neither the resource type nor the details of the drift configuration rules matter)

2)After the agent has sent the drift report to the server and before it sends the content, remove the content. This can be done by deleting the file or by changing the file contents so that it has a different SHA-256 hash. I did the latter. I should also note that I was able to get the timing of this just right by setting break points in the agent.


When the agent detects changes, it sends a drift report to the server. The server subsequently reviews the drift report looking for content that is not already in the database. 

Note that this is done asynchronously in a request different from the one sent by the agent that contained the drift report.

If the server finds that the drift report referencing content that is not already in the database, it sends a request to the agent asking for that content. By the time the agent was processing this request, I had already changed the original content such that it no longer existed.

The logic that I added in the drift details page for viewing files and diffs fails to take into account that content may not be available. In this case it is unavailable indefinitely. In other situations, maybe in scenarios involving heavier loads, the content still exists but just has not made its way to the server yet because requests are taking a long time to process.

The drift details page needs to be more robust about handling missing content. If the file to which the drift refers is text and if content is not yet available, then we need to indicate both that we supporting viewing that file and also that the content is not yet available. If content is unavailable indefinitely, then we need to indicate that as well.
Comment 5 John Sanda 2011-08-30 21:16:07 EDT
I have updated the drift details page to check for whether or not file content is already in the database. If no content is in the database for a file the corresponding 'view file' link will instead display a label saying content is not yet available. If content is not available for either the current or previous version of the file, then the link for viewing a diff will not be displayed.

commit hash: 4b12e68d2d7648ed08921f482bb02e3525a3cf81
Comment 6 Mike Foley 2011-08-31 14:15:33 EDT
possible regression with drift details page ... which i bz'd in https://bugzilla.redhat.com/show_bug.cgi?id=734879
Comment 7 Mike Foley 2011-08-31 14:25:06 EDT
another possible regression with drift details ... https://bugzilla.redhat.com/show_bug.cgi?id=734881

unable to verify this BZ.
Comment 8 Mike Foley 2011-10-05 16:38:58 EDT
verified build # 475 ... basic use-case, and with "scenario #7" network outage use-case.
Comment 9 Mike Foley 2012-02-07 14:30:21 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 10 Mike Foley 2012-02-07 14:30:37 EST
marking VERIFIED BZs to CLOSED/CURRENTRELEASE

Note You need to log in before you can comment on or make changes to this bug.