Error handling

[martinRenou]

Fix #343

Screencast.from.2024-06-04.12-43-14.mp4

[github-actions]

👈 Launch a Binder on branch martinRenou/jupytercad/error_handling

[trungleduc]

Thanks @martinRenou for working on it. I just tested with some corner cases:

• Adding shape or editing shape from the right panel does not go through the dry-run check, should we do it?

cad3.mp4

• I artificially make the loadFlle action much slower so that I can add another operator while the first one is still processing. But then the first operator is discarded, we may need to lock the operators while the worker is busy

cad4.mp4

• When there are 2 users, the first user adds an operator but since the shared doc is not updated, the second user might add another operator with the same name

cad2.mp4

• Even if the second user can avoid the naming collision, the outcome is not correct since their worker does not know about the upcoming operator of the first user

cad5.mp4

I think we might need to improve the loading indicator and locking mechanism to avoid these cases

[martinRenou]

Adding shape or editing shape from the right panel does not go through the dry-run check, should we do it?

Yes, definitely. Also we should probably do it on the first load of the file, and report malformed a file if that's the case.

I artificially make the loadFlle action much slower so that I can add another operator while the first one is still processing. But then the first operator is discarded, we may need to lock the operators while the worker is busy

Right! We should fix it indeed. It's unrelated to this PR though, so we should probably turn this into an issue and look into implementing a fix.

When there are 2 users, the first user adds an operator but since the shared doc is not updated, the second user might add another operator with the same name

I believe name conflicts should not be a thing. We can fix it by fixing #200.

Even if the second user can avoid the naming collision, the outcome is not correct since their worker does not know about the upcoming operator of the first user

I guess this would be fixed by implementing a proper lock?

[trungleduc]

yeah, having a proper operator lock definitely helps. But I also feel that having a single promise delegate for all operators might be a bottleneck. Using a dict of promise delegates and sending the delegate id back and forth between the worker and the main view model can work? In the end we only need to resolve the correct promise from worker's response

[martinRenou]

Oh I see. I'll have a look at that.

[trungleduc]

Thanks 🚀

[martinRenou]

Wait before merging I'll check to use the dry run in the object properties panel too :)

[martinRenou]

@trungleduc Ready for review!

[trungleduc]

Thanks @martinRenou

[SylvainCorlay]

🎉 that is pretty great!