Bug 1134954 - Call on apipie resource is too verbose in case of erroneous response
Summary: Call on apipie resource is too verbose in case of erroneous response
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Hammer
Version: Unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: Unspecified
Assignee: Martin Bacovsky
QA Contact: Corey Welton
URL: https://github.com/Apipie/apipie-bind...
Whiteboard:
Depends On:
Blocks: 1134809
TreeView+ depends on / blocked
 
Reported: 2014-08-28 13:46 UTC by Matej Kollar
Modified: 2023-09-14 02:46 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, API call unhandled exceptions were being passed to the client. These exceptions can be cryptic in nature. Now, when an unhandled exception happens on an API call, the error is translated to a debug message and passed to the client.
Clone Of:
Environment:
Last Closed: 2014-11-13 22:28:55 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1857 0 normal SHIPPED_LIVE Red Hat Satellite 6 server bug fix update 2014-11-14 03:28:23 UTC

Description Matej Kollar 2014-08-28 13:46:52 UTC 
Description of problem:

When called

  @api.resource(resource).call ...

returns erroneous response (say in case of creating entity that already exists)
it also prints error message in addition to re-raising exception.


Version-Release number of selected component (if applicable):
rubygem-apipie-bindings-0.0.8-1.el6sat.noarch

How reproducible: always/deterministic

Steps to Reproduce:
1. try to creat the same org twice
2. catch exception for the second and ignore it

Actual results:
  colourful message is printed 

Expected results:
  no message is printed

Additional info:
  maybe change log level to debug...
Comment 2 Martin Bacovsky 2014-08-28 14:40:17 UTC 
PR: https://github.com/Apipie/apipie-bindings/pull/15
Comment 3 Martin Bacovsky 2014-08-28 15:09:42 UTC 
The PR was merged in apipie-bindings upstream
Comment 4 Jason Montleon 2014-08-28 18:11:31 UTC 
Has a new gem been released for this? apipie-bindings is built from gem downstream and it looks like 0.0.8 is still latest.
Comment 5 Martin Bacovsky 2014-08-29 11:13:46 UTC 
Gem 0.0.9 was released.
Updated upstream spec is here https://github.com/theforeman/foreman-packaging/tree/rpm/develop/rubygem-apipie-bindings
Comment 10 Brad Buckingham 2014-09-22 13:30:16 UTC 
Matej, can you provide an example of the erroneous output and the impact of this to the user?
Comment 11 sthirugn@redhat.com 2014-10-24 19:26:24 UTC 
Nothing to test from QE stand point.  Reassigning back to lpramuk
Comment 12 Martin Bacovsky 2014-10-27 10:42:14 UTC 
The problem was that the apipie-bindings logged error caught from server and re-risen it. While it was logged on ERROR loglevel, it was difficult to hide this message even when the server error was recovered.

I'm not sure about import tool, but from hammer it could be tested while creating entity that already exists e.g. architecture:

$> hammer -d architecture create --name x86_64

In the log there should be the message form API present with DEBUG log level (instead of ERROR)
[DEBUG 2014-10-27 11:36:48 API] 422 Unprocessable Entity
Comment 17 Corey Welton 2014-11-06 15:01:34 UTC 
Verified in latest compose Satellite-6.0.4-RHEL-7-20141029.5

[DEBUG 2014-11-06 09:58:15 API] 422 Unprocessable Entity
Comment 19 errata-xmlrpc 2014-11-13 22:28:55 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2014:1857
Comment 20 Red Hat Bugzilla 2023-09-14 02:46:32 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.