We have an app that controls InDesign Desktop and InDesignServer via hundreds of AppleScripts. Some macOS security updates a while back dictated that we start communicating with other apps via ScriptingBridge. We couldn't afford to convert the hundreds of AppleScripts into direct ScriptingBridge nomenclature, so we opted to keep them as is and instead tell the external apps to: [app doScript:<the script text> language:InDesignScLgApplescriptLanguage withArguments:nil undoMode:InDesignESUMScriptRequest undoName:@"blah"] There are a handful of scripts that we did convert to direct ScriptingBridge. There are times (and under the right circumstances, it's repeatable) when a certain script will have run perfectly dozens of times, and then it will throw errOSAInternalTableOverflow. We create a new SBApplication for every job (which could be a single instance of Desktop or the multiple instances of Server). Why is this error happening seemingly randomly? Is there anything we can do to work around or prevent this?

Not quite but maybe sorta related to the errOSAInternalTableOverflow problem I asked about in a different thread, this one deals with crashes our app gets (and much more frequently lately after recent OS updates (15.7.3) are OK'd by our IT department). Our app can run multiple jobs concurrently, each in their own NSOperation. Each op creates its own SBApplication instance that controls unique instances of InDesignServer. What I'm seeing recently is lots of crashes happening while multiple ops are calling into ScriptingBridge. Shown at the bottom is one of the stack crawls from one of the threads. I've trimmed all but the last of our code. Other threads have a similar stack crawl. In searching for answers, Google's AI overview mentions "If you must use multiple threads, ensure that each thread creates its own SBApplication instance…" Which is what we do. No thread can reach another thread's SBApplication instance. Is that statement a lie? Do I need to lock around every ScriptingBridge call (which is going to severely slow things down)? 0 AE 0x1a7dba8d4 0x1a7d80000 + 239828 1 AE 0x1a7d826d8 AEProcessMessage + 3496 2 AE 0x1a7d8f210 0x1a7d80000 + 61968 3 AE 0x1a7d91978 0x1a7d80000 + 72056 4 AE 0x1a7d91764 0x1a7d80000 + 71524 5 CoreFoundation 0x1a0396a64 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 6 CoreFoundation 0x1a03969f8 __CFRunLoopDoSource0 + 172 7 CoreFoundation 0x1a0396764 __CFRunLoopDoSources0 + 232 8 CoreFoundation 0x1a03953b8 __CFRunLoopRun + 840 9 CoreFoundation 0x1a03949e8 CFRunLoopRunSpecific + 572 10 AE 0x1a7dbc108 0x1a7d80000 + 246024 11 AE 0x1a7d988fc AESendMessage + 4724 12 ScriptingBridge 0x1ecb652ac -[SBAppContext sendEvent:error:] + 80 13 ScriptingBridge 0x1ecb5eb4c -[SBObject sendEvent:id:keys:values:count:] + 216 14 ScriptingBridge 0x1ecb6890c -[SBCommandThunk invoke:] + 376 15 CoreFoundation 0x1a037594c ___forwarding___ + 956 16 CoreFoundation 0x1a03754d0 _CF_forwarding_prep_0 + 96 17 RRD 0x1027fca18 -[AppleScriptHelper runAppleScript:withSubstitutionValues:usingSBApp:] + 1036