Red Hat Bugzilla – Bug 734194
Failed to load change report viewing drift history
Last modified: 2012-02-07 14:30:37 EST
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
Created attachment 520439 [details]
Created attachment 520441 [details]
server-side log (see the end of this file)
file type = .txt
drift type = template on jboss resource
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.
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
possible regression with drift details page ... which i bz'd in https://bugzilla.redhat.com/show_bug.cgi?id=734879
another possible regression with drift details ... https://bugzilla.redhat.com/show_bug.cgi?id=734881
unable to verify this BZ.
verified build # 475 ... basic use-case, and with "scenario #7" network outage use-case.
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
marking VERIFIED BZs to CLOSED/CURRENTRELEASE