Handle stale version in delete()#989
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #989 +/- ##
==========================================
+ Coverage 93.90% 93.94% +0.04%
==========================================
Files 110 110
Lines 5902 5908 +6
Branches 332 333 +1
==========================================
+ Hits 5542 5550 +8
+ Misses 354 352 -2
Partials 6 6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| except grpc.RpcError as e: | ||
| # Handle version changes which have not yet | ||
| # propagated to PyACP. | ||
| if e.code() == grpc.StatusCode.FAILED_PRECONDITION: |
There was a problem hiding this comment.
It's good to handle this scenario but should we allow to delete an object which is out-of-date?
For me, it's similar to put modifications where the request is blocked, isn't it?
There was a problem hiding this comment.
The version tracking is - for the purposes of PyACP - hidden from the user; we expose an interface that acts as if it's always up-to-date. We also run Get + Put requests when editing an object, to ensure the edit is consistent.
When one client modifies an object and then another client deletes it, the logical combined operation would still be to delete it.
2 participants
Add a fallback to
delete()which fetches the latest object info ifthe first request fails with
FAILED_PRECONDITION.The version may become out-of-date in PyACP if a change to
a different object bumps the version in the backend (e.g., one
modeling ply affecting another's version).
Fixes #950.