BUGFIX: Replace graceful failure of field access on dataobjects #399
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a tricky one with a lot of approaches for a fix, but this is the only way that doesn't break any APIs.
The issue
versioned-snapshot-admin
is broken because it queries for fields likeabsoluteLink
andversion
on the origin record of all snapshots. Sometimes, these origins don't have those fields. The most common case is "SnapshotEvent", which is basically an arbitrary point in time -- "imported translations", e.g. , and these fields don't exist.In < 3.5, this failed gracefully, because the accessor was a simple
$obj->obj($fieldName)
. In 3.5, we've introduced theFieldAccessor
service as a new layer of abstraction. The service we use (for graphql 4 compat) isCaseInsensitiveFieldAccessor
. This implementation throws when a field is not found.This is a regression. Missing fields used to fail gracefully. Now they throw.
Option A
Remove exception from
CaseInsensitiveFieldAccessor
(API change)Option B
Add option to suppress errors to
CaseInsensitiveFieldAccessor
(complicated, and probably an API change if it's enabled by default)Option C
Update
SnapshotEvent
to include stubs forAbsoluteLink
,Version
, etc., that just return null. (Coding to the implementation, not the intention)Option D
✅ Catch the exception and fail gracefully (Implementation-specific code, as the
FieldAccessorInterface
does not say the method should throw)The chosen option D isn't great, but it doesn't break any APIs, should qualify for patch release as it fixes a regression, and it's extremely unlikely that anyone would be using a custom
FieldAccessorInterface
abstraction.Criticality
It's blocking upgrades to 4.8. We need this fix to be in a 3.5.x patch release.