Closed Bug 784352 Opened 12 years ago Closed 11 years ago

show a warning when interdiff reports errors

Categories

(Bugzilla :: Attachments & Requests, defect)

defect
Not set
minor

Tracking

()

RESOLVED FIXED
Bugzilla 5.0

People

(Reporter: glob, Assigned: glob)

References

Details

Attachments

(1 file, 2 obsolete files)

if interdiff fails to process two diffs, it outputs an error to STDERR, which ends up in the webserver error log instead of displayed to the user.

this is sub optimal.

for example:

https://bugzilla.mozilla.org/attachment.cgi?oldid=640459&action=interdiff&newid=652168&headers=1

displays no output, however interdiff reports:

1 out of 1 hunk FAILED -- saving rejects to file /tmp/interdiff-1.aqPrKk.rej
interdiff: Error applying patch1 to reconstructed file
Attached patch patch v1 (obsolete) — Splinter Review
Attachment #653758 - Flags: review?(LpSolit)
Comment on attachment 653758 [details] [diff] [review]
patch v1

Now that we require Perl 5.10.1, I think you can achieve the same goal by using autodie, which is much cleaner: http://perldoc.perl.org/autodie.html

Note that I don't really see the point to bother the user with this error message. He cannot do anything about it anyway.
Attachment #653758 - Flags: review?(LpSolit) → review-
Severity: normal → minor
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Bugzilla 5.0
Comment on attachment 653758 [details] [diff] [review]
patch v1

(In reply to Frédéric Buclin from comment #2)
> Now that we require Perl 5.10.1, I think you can achieve the same goal by
> using autodie, which is much cleaner: http://perldoc.perl.org/autodie.html

autodie's won't catch these sorts or errors, nor will it capture the error message.  interdiff is executed, so the open() statement doesn't fail.

here's what it reports:
Can't close(GLOB(0x41a2dd8)) filehandle: '' at Bugzilla/Attachment/PatchReader.pm line 131
line 131: close $interdiff_fh;
 
> Note that I don't really see the point to bother the user with this error
> message. He cannot do anything about it anyway.

displaying an error message is better than displaying a blank page, which is the current behavior.
Attachment #653758 - Flags: review- → review?
Attachment #653758 - Flags: review? → review?(LpSolit)
Comment on attachment 653758 [details] [diff] [review]
patch v1

>+        $error && ThrowUserError('interdiff_error',
>+                                 { error_message => $error });

Nit: I prefer the |ThrowUserError() if $error;| syntax, which I think is less cryptic and more intuitive than |$error && ThrowUserError();|. Also, maybe it should be a code error instead of a user error? I have no strong opinion on this.


Otherwise your patch looks good and works fine, so r=LpSolit. I'm not sure which kind of error messages we can get besides the common

    Interdiff failed to process your request:
        /usr/bin/interdiff: /tmp/QuQpVyU_YO doesn't contain a patch

The problem with this error message is that 1) it leaks paths used in your system (see the long discussion in bug 319140 about this topic), and 2) it points to the temporary file instead of the name of the original attachment (which attachment is /tmp/QuQpVyU_YO?). This makes me wonder if this error message is really useful to the user. But we can give it a try for Bugzilla 5.0, and back out the patch if we think point 1) above is not acceptable.
Attachment #653758 - Flags: review?(LpSolit) → review+
Status: NEW → ASSIGNED
Flags: approval+
in case you're wondering, i haven't committed this yet because LpSolit's concerns about the value of displaying the full error message have got me thinking.

i intend to see if interdiff ever shows a message that contains useful information ("doesn't contain a patch" isn't useful).  if it doesn't, then i suspect it would be better to display a generic "interdiff failed to process the patches" error.
from my experiments, interdiff never throws a useful error message, so a generic message would be better.  updated patch coming soon.
Flags: approval+
Attached patch patch v2 (obsolete) — Splinter Review
change to using a generic warning.

i also switched from throwing an error to displaying a warning, to allow us to display partial results if possible (eg. https://bugzilla.mozilla.org/attachment.cgi?oldid=702216&action=interdiff&newid=702770&headers=1 )
Attachment #653758 - Attachment is obsolete: true
Attachment #705772 - Flags: review?(LpSolit)
Attachment #705772 - Flags: review?(dkl)
Comment on attachment 705772 [details] [diff] [review]
patch v2

Review of attachment 705772 [details] [diff] [review]:
-----------------------------------------------------------------

r=dkl
Attachment #705772 - Flags: review?(dkl) → review+
Flags: approval?
Summary: show interdiff errors to the users → show a warning when interdiff reports errors
Comment on attachment 705772 [details] [diff] [review]
patch v2

>+        if (defined(my $error = <$interdiff_stderr>)) {
>+            warn($error);
>+            $warning = 'interdiff3';
>+        }

2 things:
- If $warning is already set by warn_if_interdiff_might_fail(), do we really want to override it?
- I fear warn($error) could fill the error log if the attachment is incorrectly formatted or for any other reason. This looks like debug code to me. It should go away, isn't it?


Holding approval till these questions are answered.
Attachment #705772 - Flags: review?(LpSolit)
(In reply to Frédéric Buclin from comment #9)
> - If $warning is already set by warn_if_interdiff_might_fail(), do we really
> want to override it?

yes, if interdiff actually throws errors, it's more important than our "this /may/ fail" warnings.

> - I fear warn($error) could fill the error log if the attachment is
> incorrectly formatted or for any other reason. This looks like debug code to
> me. It should go away, isn't it?

currently interdiff outputs its warnings to STDERR, which are logged to the error log, so this patch won't add any additional logging.  i've used it many times to determine what was happening with interdiff on our production environment.
i encountered a problem where interdiff would output "Warning: something's wrong" onto stderr, but apparently work correctly regardless.  investigating.
Flags: approval?
Attached patch patch v3Splinter Review
the problem was we were getting a defined but empty string from reading stderr, which was incorrectly triggering the warning.
Attachment #705772 - Attachment is obsolete: true
Attachment #708552 - Flags: review?(dkl)
Comment on attachment 708552 [details] [diff] [review]
patch v3

r=dkl
Attachment #708552 - Flags: review?(dkl) → review+
Flags: approval?
Comment on attachment 708552 [details] [diff] [review]
patch v3

>=== modified file 'Bugzilla/Attachment/PatchReader.pm'

>+        if (defined($error) && $error ne '') {

On checkin, please simply write: if ($error). I really doubt $error can be 0.
Flags: approval? → approval+
Committing to: bzr+ssh://bjones%40mozilla.com@bzr.mozilla.org/bugzilla/trunk/
modified Bugzilla/Attachment/PatchReader.pm
modified template/en/default/attachment/diff-header.html.tmpl
Committed revision 8571.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Blocks: 839095
Blocks: 845725
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: