For the other part of it, where you hit the [New] button and nothing shows up on the UI until a /console reloadui I have a feeling it might be some kind of race condition, because I've had it happen intermittently not just on the objective level but also when adding a new id for a tracker (more rarely)

1. Hit New, nothing happens, reloadui and it's there with the default "New" name (or if you made multiple attempts New 2, New 3 etc)
   Other times it works to populate the objective tab with default values and show the new entry in the dropdown top right.

2. Similarly I've had it type in an item id into the tracker editbox, hit Okay and the list of tracked items does not update (it is not a misstyped item id as it shows up after a reloadui as well)
   This happens more infrequently than 1 but I've seen it as well. (no Lua errors in either case)

Originally posted by @Road-block in #30 (comment)

Closing this ticket since there hasn't been any other reports of issues and I haven't encountered it in a while either. As usual feel free to reopen if you find more info.

As of right now, I'm still having issues replicating the problem. What do you mean by race condition?

I'm pretty sure I got no Lua errors (I'm using BugGrabber + Bugger, they keep errors cross-session I double checked)
What I meant by race condition is that perhaps AceGUI under some condition (could even be related to the users PC performance, or what else is happening in the script environment at the moment) tries to refresh widgets before the relevant table structures have finished instantiating, finds nothing.

After a reloadui since the tables are already present, it populates its widgets just fine.

But I'm just guessing.

Are you sure there were no lua errors? I'm not sure how I got it to happen, but when trying to add a tracker, I got a lua error and nothing showed up. I fixed the error that showed up, but I don't know if that was it or some other thing. Either way, the error shouldn't have happened because for some reason it didn't return a valid tracker key.

The problem here is how to test something that only happens sometimes, I haven't found a way to reliably reproduce.

I could edit my local copy to have RefreshOptions() run on the next frame and create a bunch of objectives and see if it happens again.

I would essentially go here Options.lua:L76 in my local copy and change it to

    C_Timer.After(0,function() -- next frame
        LibStub("AceConfigRegistry-3.0"):NotifyChange(addonName)
        LibStub("AceConfigRegistry-3.0"):NotifyChange(addonName.."ObjectiveEditor")
    end)

so it does a one frame delay before messaging AceGUI no matter where RefreshOptions is called from.

Now that I know what you mean, I think you may be on to something.

In RefreshOptions, the call to update the objective builder is the one that would handle changes to trackers.

Perhaps it calls the refresh function, then notifies the changes after the call is initiated but before the refresh has completed.

I'm not sure how the inner workings of Lua are to know it that's a possibility or not but sounds plausible.