cutting a previously-cut assignment: assignment not found - resolved with since/0

[caver456]

Reported by Steve 3/6/23, duplicated on sartopo.com 4/7/23:

I have been testing plans console. A test is to cut an assignment with a line. This works. Then, cut the original (yet smaller) assignment again with a new cut line. The original shape cannot be found (although it exists on the map and in the exported json).

I modified the send Request in line 470 of sartopo_python, changing the 2nd argument to 'since/0' .

Restarted plans console and cut an assignment (worked as expected) Then recut, this time the assignment was found and cut as expected.

Is there an update issue wrt since timing and the shape getting modified? Or an issue with my test case?

On the re-cut attempt, the message 'Cut operation failed: Selected feature "abc" not found."

[caver456]

It kind of looks like the since response after the cut operation is setting title to a single space. In this sync dump file (which shows the content of the response to the since request) immediately after the cut operation, the geometry does reflect the correctly cut assignment:

"state": {
         "features": [
            {
               "geometry": {
                  "coordinates": [
                     [
                        [
                           -120.74031898989298,
                           39.162536848382004
                        ],
                        [
                           -120.66284353515626,
                           39.24288970281078
                        ],
                        [
                           -120.56808645507813,
                           39.21629530656301
                        ],
                        [
                           -120.63537771484376,
                           39.113013663506344
                        ],
                        [
                           -120.7376986783926,
                           39.140974447714754
                        ],
                        [
                           -120.74031898989298,
                           39.162536848382004
                        ]
                     ]
                  ],
                  "type": "Polygon"
               },
               "id": "be302f98-55a4-4d54-9c3e-14e3d879c097",
               "type": "Feature",
               "properties": {
                  "class": "Assignment",
                  "updated": 1680990357000,
                  "nop": true,
                  "title": " "
               }
            },

[caver456]

Probably the cleanest way to avoid clobbering the title is to remove 'title' from the list of properties to update in the cache on a sync response. Maybe nop=true is meant to indicate that nothing changed besides the geometry? Who knows.

[caver456]

When editing a shape by hand, the subsequent since response contains all properties. So, why does the response here contain only a few properties including the incorrect title?

Watching the outgoing request during a chrome geometry edit shows that all properties are sent in the same request as the edited geometry. That's probably what causes all properties to be in the response. So, it's probably actually safer to do this same workflow, to more closely mimic the 'normal' behavior as if the geometry were edited in a web browser.

[caver456]

Interestingly: the outgoing request doesn't include title - just letter and number. The response does include title (with no trailing space if number is blank).

Also, the response includes the updated timestamp, which probably isn't completely necessary to add to the cache, but, also probably won't hurt - so there's no specific need to add code that excludes 'updated'.

[caver456]

Yup - a small change to editFeature to send all of the feature's existing properties in the request, overwritten by any arguments to that function, does the trick. The same feature can now be cut repeatedly in the same plans console session.