Intermittent failure add-in communicating with palette

[Anonymous]

Hello, I have a fairly complex Add-in I am developing. The back end is Python that communicates with a GRBL controller over serial. The front end is an HTML palette. The backend sends status updates once a second. Things generally work well, but I occasionally get the error described by the screen shot. I'm developing the front end in Angular. This is the backend code handling the event fired from threads, I've marked the line that is failing:

# The event handler for messages sent from the back end actors
class ActorEventHandler(adsk.core.CustomEventHandler):

    @trap_error
    def notify(self, args):
        msg = adsk.core.CustomEventArgs.cast(args).additionalInfo # this is failing
        index = msg.find(":")
        event_name = msg[: index]
        data = msg[index + 1 :]

        # Send information to the palette. This will trigger an event in the javascript
        # within the html so that it can be handled.
        palette = _ui.palettes.itemById(paletteId)
        if palette:  # palette not found if closed
            try:
                palette.sendInfoToHTML(event_name, data)
            except:
                # todo: log
                pass

I'm using threading (an Actor implementation called Pykka.) This is how I'm firing the events from the threads:

_app.fireCustomEvent(paletteEventId, "{}:{}".format(event_name, data))

Can I get some idea of what is going on? As I said it generally works, occasionally fails. Unfortunately once if fails the first time I have to force quit F360 as the error pops up once a second with no way for me to stop the add-in. So it looks like some state changes and event firing will no longer work.

Thanks.

/Daryl

[KrisKaplan]

Luckily, the '!response.empty()' validation error from your exception traceback helps identify what is going on here.  This exact validation is not made in the 'additionalInfo' call.  In fact, it is only used in the 'Palette.sendInfoToHTML' API.  What is happening is that a call to sendInfoToHTML (presumably on the main thread) set a last error value (normally obtainable from Application.getLastError()).  And the call to CustomEventArgs.additionalInfo on the thread saw this last error still set when it was complete.  The Python API wrapper makes the API call, and then checks if a 'last error' was set, and if it was, it throws it as an exception.

The problem is that this 'last error' value is held in thread local storage.  But due to an error, for the Mac compilation this last error was not properly using thread local storage.  So the last error from another thread could be treated as an error set on the last API call on a different thread, and thrown as an exception in Python (after an otherwise successful API call).  This should be an easy fix on our side and I filed an issue for this.

In the meantime, you may be able to reduce (but probably not eliminate) the likelihood of this happening by making a trivial API call (for example 'Application.get()') in the 'catch' clause of the function making the call to sendInfoToHTML.  Every new API call clears the last error, so assuming the failing sendInfoToHTML call and this new call in the handler clearing the last error should reduce the length of time this last error is pending and could interfere with the call on the thread.  Another option would be to just wrap this call to additionalInfo in a try block and retry the call a few times (if one call overlaps an error on the main thread, it is not likely to recur if retried).  But note that any failing API call on a thread could interfere with any API call on another thread in a similar manner until the fix for this is available.  The only reliable way to avoid it in your code would be to use a mutex between your threads and avoid making concurrent API calls.

Kris

[JeromeBriot]

---

@KrisKaplan wrote:

This should be an easy fix on our side and I filed an issue for this.

---

Hello,

Any news about this issue? I think I'm facing the same one.