-
Notifications
You must be signed in to change notification settings - Fork 263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JobResult view should robustly handle cases where data
format is not as expected
#453
Comments
Personally I'd love to address this via a larger JobResult rework that would move log entries into their own separate standalone data model and return |
#1030 may address this - need to circle back here and verify. |
Yes it does, I knew I was missing one, but couldn't find it. Adding to the Fixes... |
Fixed by #1030. |
Environment
Steps to Reproduce
Job
or vianbshell
, create or modify aJobResult
object so that itsdata
attribute is formatted differently than the "standard" data format constructed and modified by callingJobResult.log
, for examplejobresult.data = {'hello': 'world', 'this': ['is', 'a', 'list'], 'logger': {'log': [['x', 'y', 'z', 'p', 'd', 'q', 'b', 'b', 'q']]}}
.extras/job-results/
, click on the timestamp link, as if to view details of this JobResult recordExpected Behavior
JobResult detail view should render successfully:
data
should be displayed as a fallback option.Alternatively (though in my opinion less desirably) the JobResult
clean()
orsave()
APIs should verify that the data format is as expected and reject any attempt to create data that does not conform to the format.Observed Behavior
ValueError is thrown, for example:
The text was updated successfully, but these errors were encountered: