-
Notifications
You must be signed in to change notification settings - Fork 1
Fix EdgePropertyList construction via _from_object_info #562
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
Fix EdgePropertyList construction via _from_object_info #562
Conversation
|
@roosre this is a fairly significant bugfix, I'd suggest we do a |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #562 +/- ##
==========================================
+ Coverage 91.93% 92.91% +0.97%
==========================================
Files 82 82
Lines 4242 4291 +49
==========================================
+ Hits 3900 3987 +87
+ Misses 342 304 -38 ☔ View full report in Codecov by Sentry. |
40f457c to
c9a0a48
Compare
4d7db86 to
b6bd031
Compare
Fixes #561
The
EdgePropertyListretains the same list instance during its lifetimefor containing the edge property wrappers. This is done so that references
user code might hold to its items to correctly update its contents.
In contrast to other types, it means that the state is not re-fetched from
the
_pb_objectif it were to change outside of theEdgePropertyList'scontrol.
This led to a bug when constructing objects via
_from_object_info, whichfirst default-constructs the object (in the process creating the
EdgePropertyList)and then modifies the
_pb_object.To fix this, the
EdgePropertyListnow stores whether its parent object wasstored when this list was last accessed. If it changes from unstored to stored,
the following logic is applied:
for matching length is performed
case which occurs during construction with
_from_object_infoSince the edge property list can be in an inconsistent state (empty when it shouldn't
be) while the parent is unstored, we disallow accessing it in this state. It is still
allowed however to fully replace the contents.
This PR also fixes a bug in
tree_object_from_resource_path, where thechannelargument was still used instead of
server_wrapper.