Open niels opened 5 years ago
@niels Your issue might be related to the one I just posted #38 -- see my comments there.
I think the fix is two-fold:
if ID
s are going to be strings in graphiti responses then graphiti_errors
should make the id
in the validation payload a string -- or spraypaint can force compare them as strings.
Spraypaint should check the temp_id
/ temp-id
for it's presence before potentially comparing two undefined
values for equality.
I provided a standalone Javascript demonstration of the bug.
I submitted a PR here: #39
@niels: I ran into issues related to deeply nested errors as well (see https://github.com/graphiti-api/graphiti_errors/issues/8). graphiti_errors
is not returning enough information for Spraypaint to properly target the correct object.
Considering using this library but old issues that are not dealt with or closed gives pause. Is this actively maintained?
Forgive me if this is an operator error, but I think we're seeing Spraypaint being unable to cope with graphiti produced validation errors on (deeply) nested relationships.
We have a
Delivery 1 <> n ContentsVersions 1 <> n Contents
relationship which is modelled server-side roughly like so:Our Spraypaint models correspondingly look something like this:
When we try to create a
Delivery
side-posting aContentsVersion
with aContent
, but theContentsVersion
fails to validate server-side, we get this error:The error gets raised when trying to parse the error related to the
Contents#content_version
presence validation. Please find a full copy of our version of the_processRelationship
function further below.Our request payload looks like this:
Note that this payload format seems to be correct. When we send data that passes the validation, all resources get created correctly. With invalid data, however, the servers responds as follows:
From this error response, Spraypaint does not seem able to figure out that the second object relates to the deeply nested Delivery => ContentsVersion => Content.
Annotated with payloads: