Hi,

The best way to avoid this is to not have a JavaScript exception. I'm also not sure it is a bug but as you say APEX could be more robust. I can describe what is happening and why edit never works again.

When the value of a cell is going to be updated asynchronously the lockActive method must be called before the async action (for example an ajax request) and unlockActive must be called after. The reason for this is that the edited row must remain locked so that any async updates apply to the correct row. The user can't keep editing a new row until all async edits to the current row are complete. This is all explained in the help for these methods (https://docs.oracle.com/en/database/oracle/application-express/18.2/aexjs/grid.html#lockActive ). This is handled automatically for dynamic actions because the IG region interface supports the getSessionState method and the beforeAsync and afterAsync callbacks. This part of the region interface is not currently documented and you would have to look at the code. But you don't need to know about that just that lockActive and unlockActive are called automatically from the server.js module around the ajax request that is done by the Set Value DA.

If there is an exception or other kind of JavaScript error while processing the async action then unlockActive will never be called. This is why the grid can not be edited after the error.

You can prove that this is the problem on your demo app by doing this after the error:

apex.region("R88887452800659125901").call("getCurrentView").view$.grid("unlockActive")

Then you can edit again.

So it could be that APEX should have a try catch handler somewhere to protect against this. In general APEX library doesn't have a lot of try catch blocks. The general philosophy is that the developer provided code should not have errors or exceptions and if it does it should fail fast at the point of error. The practical reason is that lots of try catch can slow JavaScript down.

Regards,
-John