Closed Bug 657561 Opened 13 years ago Closed 13 years ago

Invalid XMLRPC response generated if an optional custom int field is empty

Categories

(Bugzilla :: WebService, defect)

4.0.1
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Bugzilla 4.0

People

(Reporter: gyp, Assigned: gyp)

Details

(Whiteboard: [4.0 only; AUTOLOAD is gone in 4.2])

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.16) Gecko/20110323 Ubuntu/10.04 (lucid) Firefox/3.6.16
Build Identifier: 4.0.1

The bug that can be seen is similar to that in bug #477593 but with other fields: when we have some int-type custom fields which are optional, XMLRPC web service generates an empty <int/> tag in the response, which is considered invalid by most clients (including python's xmlrpclib, which I wanted to use) and cause them to whine.

After lots of digging, I managed to find the root of the problem. You see, XMLRPC handles it well if it receives "undef" in such a field and does not include it in the output, however, the underlying layers mess with it badly. The problem is that that at some point, _bug_to_hash() calls something like $bug->the_name_of_my_custom_and_empty_int_field, which goes to the magic AUTOLOAD thing in Bug.pm, which breaks things. The problem is with the following:

return $self->{$attr} if defined $self->{$attr};
[...]
return '';

Now, as $bug->the_name_of_my_custom_and_empty_int_field is explicitly set to "undef", it won't be returned with that value, but instead as an empty string. Which will bubble up to the XMLRPC layer, and cause it to include the invalid empty <int/> tag.

My proposed fix is to change the "if defined" condition to "if exists", which is what I think we want to do here.

I'm aware that this whole AUTOLOAD mess has been cleaned up in bug #600123, which is in the trunk now and proposed for 4.2, however, I don't have the resources now to test it with that code -- my change fixed the problem for me in a 4.0.1 and caused no other problems. So feel free to either include this fix in the 4.0 branch for a future 4.0.2 maintenance release (if you do those) or set this to a dup of #600123 after testing that that change also fixed this -- honestly, I'm a bit terrified of Perl so I couldn't figure it out only based on the code :)

Reproducible: Always

Steps to Reproduce:
1. create an int-type optional custom field
2. create a bug where it is not filled in
3. fetch this bug through the XMLRPC API

Actual Results:  
The response includes an empty <int/> tag for that custom field, which is considered invalid by most XMLRPC clients.

Expected Results:  
The whole custom field should be omitted from the results if it's blank, just as it happens for built-in fields, like dup_id.
Wow, what an interesting bug, thank you for the report! Your fix sounds like a pretty good idea, do you think you could provide a patch? If not, we can just do it ourselves.

I'm slightly worried about changing anything regarding the AUTOLOAD on a stable branch, though. It's caused strange regressions before. Particularly if we start returning "undef", we might start generating a lot of warnings. So we may not be able to fix the problem that way on the 4.0.x branch.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: x86_64 → All
Target Milestone: --- → Bugzilla 4.0
(In reply to comment #1)
> Wow, what an interesting bug, thank you for the report! Your fix sounds like
> a pretty good idea, do you think you could provide a patch? If not, we can
> just do it ourselves.

Certeanly, I'll attach a patch against the 4.0 head in bzr in a minute. Consider it having a Signed-off-by: Peter Gyongyosi or whatever licensing thingie you need :)


> I'm slightly worried about changing anything regarding the AUTOLOAD on a
> stable branch, though. It's caused strange regressions before. Particularly
> if we start returning "undef", we might start generating a lot of warnings.
> So we may not be able to fix the problem that way on the 4.0.x branch.

You're indeed right about worrying about this. My first intuition was to change the default-fallback of returning an empty string to return undef, but that, while fixing the XMLRPC interface, triggered errors in the Web UI. This patch, however, seems to work properly, I haven't seen any warnings ever since I made the change.
Comment on attachment 533200 [details] [diff] [review]
making Bug.pm's AUTOLOAD hande undefs better

This looks good to me, but LpSolit, do you think this will cause regressions on the 4.0 branch?
Attachment #533200 - Flags: review?(LpSolit)
(In reply to comment #4)
> This looks good to me, but LpSolit, do you think this will cause regressions
> on the 4.0 branch?

Hard to say without some more testing (won't happen today), but from what I can see in AUTOLOAD, if $self->{$attr} is undefined and $attr doesn't point to a custom multi-select field, we return an empty string. With this patch, we would suddenly return undef instead. I guess there are some places where the caller doesn't expect to get an undefined value and could either throw warnings or die (for instance, trick_taint() explicitly dies if it gets undef). This makes me nervous.

Also, this would need to be tested against 4.0.2pre as it may interact with bug 653263.
Whiteboard: [4.0 only; AUTOLOAD is gone in 4.2]
Version: unspecified → 4.0.1
With this patch applied, webservice_bug_search.t throws:

"Use of uninitialized value in string eq at webservice_bug_search.t line 147."

Line 147 is:

            ok(!grep($_->{alias} eq $private_bug->{alias}, @$bugs),
               'Result does not contain the private bug');

mkanat: as far as I can tell, the alias can be undefined, as NULL is a valid value in the DB. So this test script should be fixed. I saw no other errors due to this patch.
Comment on attachment 533200 [details] [diff] [review]
making Bug.pm's AUTOLOAD hande undefs better

I think this change makes sense, and the QA script mentioned above will need to be fixed. r=LpSolit
Attachment #533200 - Flags: review?(LpSolit) → review+
We need to relnote this for devs using our WebServices. E.g. alias is not undefined rather than empty, as mentioned in comment 6. Also, bug ID custom fields are also undefined rather than empty when not set.
Assignee: webservice → gyp
Status: NEW → ASSIGNED
Flags: approval4.0+
Keywords: relnote
(In reply to comment #8)
> We need to relnote this for devs using our WebServices. E.g. alias is not
> undefined rather than empty

I meant "... alias is now* undefined ..."
Thanks for reviewing and merging this. Frédéric, in comment #8, you've assigned this bug to me. Is this only for administrative reasons or I am expected to do something?
(In reply to comment #10)
> assigned this bug to me. Is this only for administrative reasons or I am
> expected to do something?

Only for administrative reasons (so that we can easily know who fixed the bug). I will commit your patch in the source code later today. :)
I did some more testing, and with this patch, Bugzilla 4.0.2 now behaves exactly the same way as Bugzilla 4.2, i.e. we return undef rather than an empty string when a field is undefined.

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/4.0/
modified Bugzilla/Bug.pm
Committed revision 7614.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
For the record, I also fixed webservice_bug_search.t:

Committing to: bzr+ssh://lpsolit%40gmail.com@bzr.mozilla.org/bugzilla/qa/4.0/
modified t/webservice_bug_search.t
Committed revision 191.
I'm sorry I didn't comment on this earlier, but it's not okay to change the API of a stable WebServices function that way on a stable branch. There could be implementations which depend on receiving that hash element and may fail when it is suddenly not present at all. (This is more likely in strictly-typed languages but could happen anywhere.)

In fact, if this behavior changed in 4.2, it should be added to History. You can keep this patch, but don't break the WebServices API.
Status: RESOLVED → REOPENED
Flags: blocking4.0.2+
Resolution: FIXED → ---
Actually, thinking about this further, I agree that it's better to generate valid XML-RPC than to retain a stable API for a very minor thing. So we will simply relnote it as LpSolit mentioned.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Already added to relnotes for 4.0.2.
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.