Micke -
In your expectations, keep in mind that you’re dealing with at least one coder who cannot delete an area or deadend without recursively deleting everything that references it.
4 Likes
It’s a safety feature. 
2 Likes
LOL. Aptly put.
Definitely do not doubt you. You’re not the first that has said as much. I just know what it’s supposed to do, and it doesn’t always do this. Perhaps they changed something, hard to say. The release notes are not as all inclusive as they should be.
3 Likes
I completely understand your concern about route optimization. This is indeed one of the areas we aim to improve in future updates. We’ve observed this behavior before and have already shared it directly with our product team, but I will pass your feedback along to them again to reinforce its importance. Thank you for bringing this to our attention.
1 Like
Is there any other way?
Absolutely!
The pathway/area/dead-end data should simply be stored as independent coordinates. There’s no technical reason why deleting one should cause all the others to disappear (recursive delete).
I can think of a few possible explanations for why this happens:
-
Legitimate concerns about accuracy
-
The system might be worried about inaccuracies, map drift, or GPS alignment issues after remapping.
-
If that’s the case, they could solve it by implementing a user confirmation step, for e.g., “We’ve detected possible changes to the map. Do you still want to keep these coordinates?” instead of wiping everything. And the user could move the rover at say, two points in the area so Yarbo can confirm that everything is still all good… (not even sure it would be required if you confirm the dock is ok).
-
-
Poor data structure design
-
A more worrying possibility is that the pathways, areas, and dead-ends are embedded into each other in the code, so they are not truly independent.
-
This suggests a lack of database normalization, meaning the system treats them as a single dependent chain instead of individual entries. In good design, each pathway, dead-end, and area should be stored separately and referenced by ID, so removing one doesn’t cascade unnecessarily.
-
-
Overly aggressive safety logic
- The deletion algorithm might have been written with a “better safe than sorry” mindset, removing anything that might be indirectly related to the deleted object, even if that’s excessive.
-
Legacy code constraints
- If the feature was built on older code, it might be using outdated methods that don’t support independent deletion well, and fixing it would require a deeper rewrite.
-
Simplified implementation for speed
- Sometimes developers choose the quickest approach to meet a release deadline, in this case, treating all related coordinates as one object may have been a shortcut to avoid edge cases during development.
Of course, a lot of speculation here, but from a software development perspective, this should be fixable. The real question is how deeply these dependencies are embedded in the code and how much refactoring would be needed to separate them.
1 Like
I was referring to @steve’s obsessive recursive deletion. I suffer from the same affliction.
But yes, there should be many ways to align the virtual world to the physical one.
1 Like
And I replied about reasons for the recursive deleting… It is possible to do that without deleting everything and I listed reasons why right now it might be an hard to fix….
2 Likes
There’s no legitimate reason for deleting a task when we delete an area or DeadEnd that is selected in that task.
None.
They do it because it never occurred to someone that a task might not have any selected areas / DEs in it. It’s a stupid, pointless oversight, and the sole reason for it is that they cannot handle an empty task. Someone literally could not comprehend what to do if you delete the last existing area/item/whatever that is selected in a task. So they delete the task if you touch any thing in it.
Heaven forbid we should invoke a task that has no areas selected. That’d require rocket science for the task engine to… uh, do a foreach that exits immediately. Or, you know, see if the element count is 0 before you solve it.
It’s embarrassing.
3 Likes
Micke,
Nothing you typed has anything to do with deleting an item from an array or linked list, let alone deleting the entire task array or list because one element was removed.
1 Like
Yeah, I get you now, but I think we took the same problem differently… I’ve seen such code behaviors in other situations than an empty array, that is rooted in something much more deep in the code… that “might” offer an alternative to this recursive deletion…
You’re saying the root of it is the task engine just can’t handle an empty set of areas/DEs, so instead of letting the task sit empty (and just skipping it), it nukes the whole thing. Totally agree that’s a silly oversight if that is the case and an easy fix with a simple “if count == 0” check or something.
I was looking at it from the other angle… That maybe this behavior comes from deeper dependency issues in how the data’s structured. If the tasks, areas, and DEs are coded in a way that they reference each other in a chain (which is totally plausible IMO) you get the “recursive deletion” effect where removing one element wipes out everything tied to it. If it’s just the empty-task logic, quick patch. If it’s embedded dependencies, then it’s a bigger refactor. Either way, still fixable.
But let’s agree that we should not be arguing about such a thing as clients of a lawn mower haha…
2 Likes
Steve:
Ok, if they coded it using plain arrays, then sure your point stands. But what I’m trying to explain is how this could happen in a way that makes it harder for them to fix. I honestly struggle to believe it’s as simple as “empty array deletes task.”
For example if each task stores direct object references to the areas/DEs instead of just IDs, and those objects are embedded rather than independent, removing one could automatically invalidate the whole task. If it’s coded like that, fixing it would require more refactor. Don’t you agree?
It would look more like this than a simple array of IDs:
struct Task {
std::vector<Area> areas; // Stores actual Area objects here, not just IDs
void removeArea(size_t index) {
areas.erase(areas.begin() + index); // Remove the area
// If empty, dev assumes "task is useless"
delete this; // <-- boom, task gone
}
};
1 Like
< looks around the room. / > From Yarbo?
1 Like
I don’t think its that complicated. If you manually remove a DE from a plan and then delete the DE the previously associated plan isnt deleted. But if you delete the DE while its a member of a plan the whole plan gets deleted.
4 Likes
oh! Did not notice that… sounds like this might be one of those cases where the “huge scary bug” turns out to be nothing more than bad delete logic. Sometimes the monster under the bed is just a squeaky floorboard….
3 Likes
If that’s the case, it’s another simple fix that just doesn’t get implemented. Those are very frustrating.
2 Likes
Please confirm what I said is consistent in all cases. Create a dummy work plan and add a DE or NGZ and delete the DE/NGZ when it is part of a plan and when it isn’t.
It’s easy to see how such codebase would evolve.
In the beginning, they wrote a task “object” that only allowed for one area to be snow-blowed.
Hilarity ensued when someone then made it into an array for multiple areas, but the element delete handler IS THE APP when it completely overwrites the task with the new version.
/sigh
1 Like
I think I get our “misunderstanding” now. I honestly wouldn’t have thought Steve’s scenario possible… if that’s how it happened, then yeah, that’s pretty dumb. Taking a single-area task, swapping in an array, and leaving the old “nuke the whole thing” delete logic in place would totally explain it… but it still feels too dumb to be true.
One way you could get the same behavior (and the one I was thinking of in my first post) is if the DE → Task link is set up in the database or ORM with an ON DELETE CASCADE. In that case, deleting a DE that’s still linked to a task would automatically wipe the task, but unlinking first would leave it intact (exactly what JNS described). That’s less about bad array code and more about how the relationships are defined in the data layer, which is trickier to untangle.
If it’s this, it would basically support my point from earlier: the problem might be baked into the underlying data structure. it would also give them a legitimate reason for not just slapping on a “quick fix.”
This would reproduce the bug:
CREATE TABLE DeadEnds (id INTEGER PRIMARY KEY);
CREATE TABLE Tasks (id INTEGER PRIMARY KEY);
CREATE TABLE TaskDeadEnds (task_id INTEGER,deadend_id INTEGER,FOREIGN KEY(deadend_id) REFERENCES DeadEnds(id) ON DELETE CASCADE);
2 Likes