Project

Profile

Help

Task #2271

Plan Structured Exception Storage

Added by bmbouter about 3 years ago. Updated 6 months ago.

Status:
MODIFIED
Priority:
Normal
Category:
-
Sprint/Milestone:
Start date:
Due date:
% Done:

100%

Platform Release:
Blocks Release:
Backwards Incompatible:
Yes
Groomed:
Yes
Sprint Candidate:
Yes
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:
Sprint 10

Description

In 2.y and currently on 3.0-dev branches, Exception objects are stored inconsistently. It is backed by two json fields. One is for storing non-fatal exceptions, and another is for storing a single fatal exception field.

When saving an exception, the exception type will give you different types of information. Here are the current behaviors:

Exception -- you'll get the entire traceback as one string. It includes the Exception name and message, but it's not structured which means the API can't structure it easily either. The traceback is logged once in the logs.

PulpException -- same as exception

PulpCodedException -- you'll save a dictionary with the following keys: 'code', 'description', 'data', and 'sub_errors'. What you won't save is the type (besides the 'code') or message (maybe that's 'description'?) or the traceback in any way. The traceback is logged once in the logs, but regularly we have users who are not the admins and don't know where the logs are try to find that one line. Also sub_errors allows for recursive nesting.

With ^ in mind here are some questions:

  • Do we want a dictionary in all exception cases with 'traceback' and 'message' as keys?
  • Should 'code' also be there but be None when not set?
  • Do we want to keep sub_errors and the recursive storage?
  • Should we structure tracebacks better or is this a client side issue?

Associated revisions

Revision 9a37b213 View on GitHub
Added by dkliban@redhat.com almost 3 years ago

Replaces PulpCodedException with PulpException

The new PulpException should be used as a base class for each Pulp coded exception.

closes #2271
https://pulp.plan.io/issues/2271

Revision 9a37b213 View on GitHub
Added by dkliban@redhat.com almost 3 years ago

Replaces PulpCodedException with PulpException

The new PulpException should be used as a base class for each Pulp coded exception.

closes #2271
https://pulp.plan.io/issues/2271

Revision 9a37b213 View on GitHub
Added by dkliban@redhat.com almost 3 years ago

Replaces PulpCodedException with PulpException

The new PulpException should be used as a base class for each Pulp coded exception.

closes #2271
https://pulp.plan.io/issues/2271

History

#1 Updated by semyers about 3 years ago

As this relates to the REST API, http://www.django-rest-framework.org/api-guide/exceptions/ has some guidance on how to make sure what we come up with is well-represented in the API.

#2 Updated by mhrivnak about 3 years ago

  • Description updated (diff)

#3 Updated by mhrivnak about 3 years ago

  • Groomed changed from No to Yes

#4 Updated by mhrivnak about 3 years ago

  • Sprint/Milestone set to 27

#5 Updated by jortel@redhat.com almost 3 years ago

  • Sprint/Milestone changed from 27 to 28

#6 Updated by dkliban@redhat.com almost 3 years ago

  • Status changed from NEW to ASSIGNED
  • Assignee set to dkliban@redhat.com

#7 Updated by dkliban@redhat.com almost 3 years ago

  • Status changed from ASSIGNED to MODIFIED
  • % Done changed from 0 to 100

#8 Updated by bmbouter over 1 year ago

  • Sprint set to Sprint 10

#9 Updated by bmbouter over 1 year ago

  • Sprint/Milestone deleted (28)

#10 Updated by daviddavis 6 months ago

  • Sprint/Milestone set to 3.0

#11 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF