Closed caver456 closed 1 year ago
These lines from the transcript, just above the 'interesting' part (the first horizontal line) seem to be the key - but why is this happening?
INFO:root: Deleting Shape:a7
INFO:root: Deleting Shape:a8
Added code to dump the since response as well as the cache (.mapData dictionary) for each sync event, with filename based on the lastSuccessfulSyncTimestamp. Based on this, the since response looks correct (i.e. the objects that get deleted from the cache aren't referenced in the since response at all, and there is no 'ids' key that would indicate what should be deleted) but the code is deciding to delete them from the cache anyway. So - need to do a closer look at the cleanup code that deletes things from the cache.
Looking again at this year-and-a-half-old issue while getting ready for a new pip release. Was not able to reproduce the issue on multiple runs of the same geometry operation test bench (geomTest.json and test.py). The only occurrences of 'not found' were for 'foo' and 'bar' as expected, and all the geometry operations appeared to run correctly. Closing this issue, since there were a LOT of changes to the code over the last year and a half, and for now we have to assume that one of those changes resolved this issue.
The initial symptom is a group of failed geom operations (expand a7 b7, and cut a8 b8).
Here's the full transcript, with the most interesting portion between the lines. After looking at the transcript, checking the sync dump file shows that id 630eab7d-7a28-4aaf-baee-4c7b38390d73 (a7) is listed in 'ids' but is not present anywhere else in the dump file. b7 is a feature in the sync dump file; a8 is not; b8 is.
So, when editObject says that there is no match, it is telling the truth, and the geom operation gracefully exits as expected. But why are the features missing? Maybe a sync race condition?
Workaround: if you just run the same test code again, it works fine. This adds credibility to the race condition theory.