Another crash log added to the bug, in case it helps.

I have a small external app that puts up a modal dlog on receipt of the openDocuments event. I created a fake job in the big app that sends all the events, and had it send an kAEOpenDocuments to the small app, using kAEWaitReply so it will just sit there until the small app dismisses the modal dlog. I then ran a normal job that hammers InDesign with thousands of scripts. I got this in the Xcode log of the big app: AddInstanceForFactory: No factory registered for id <CFUUID 0x600003aad120> F8BB1C28-BAE8-11D6-9C31-00039315CD46 A few minutes later the big job got stuck and I noticed two of these in the Xcode log: Received XPC error Connection interrupted for message type 1 kCFNetworkAgentXPCMessageTypePACQuery The big job's thread at this point: ProofProcessor - FAKE1 Queue : Job Queue (QOS: USER_INITIATED) (concurrent) #0 0x00000001948e1c34 in mach_msg2_trap () #1 0x00000001948f43a0 in mach_msg2_internal () #2 0x00000001948ea764 in mach_msg_overwrite () #3 0x00000001948e1fa8 in mach_msg () #4 0x0000000194a0ec0c in __CFRunLoopServiceMachPort () #5 0x0000000194a0d528 in __CFRunLoopRun () #6 0x0000000194a0c9e8 in CFRunLoopRunSpecific () #7 0x000000019c434108 in ___lldb_unnamed_symbol1373 () #8 0x000000019c4108fc in AESendMessage () #9 0x00000001e11dd2ac in -[SBAppContext sendEvent:error:] () #10 0x00000001e11d69d8 in -[SBObject sendEvent:id:format:] () #11 0x00000001e11d43d8 in -[SBElementArray count] () #12 0x00000001949ba7e4 in -[NSArray getObjects:range:] () #13 0x00000001949feae0 in -[NSArray countByEnumeratingWithState:objects:count:] () #14 0x0000000102b27054 in -[InDesignHelper(ScriptingBrigePageItems) idsAndLabelsOfAllPageItemsRecursivelyForDocSB:includeMasterSpreads:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelperScriptingBridge/InDesignHelperSBPageItems.m:105 #15 0x0000000102c90704 in __82-[InDesignHelper idsAndLabelsOfAllPagesItemsRecursivelyforDoc:includeMasterPages:]_block_invoke at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:2887 #16 0x0000000102ce8820 in -[InDesignHelper _callSBMethod:scriptName:docID:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:6160 #17 0x0000000102c901d4 in -[InDesignHelper idsAndLabelsOfAllPagesItemsRecursivelyforDoc:includeMasterPages:] at /Users/xxx/Documents/gitdepot/RRDFramework/InDesignHelper.m:2887 #18 0x00000001008c7dc4 in -[FakeProof allPageItemIDs] at /Users/xxx/Documents/gitdepot/MMAutomation/FakeProof.m:302 #19 0x00000001008c3bf4 in -[FakeProof _doProofProcessing] at /Users/xxx/Documents/gitdepot/MMAutomation/FakeProof.m:89 #20 0x000000010094da10 in -[ACDCProof processProof] at /Users/xxx/Documents/gitdepot/MMAutomation/ACDCProof.m:133 #21 0x0000000100ab3300 in -[ProofProcessor _processDriverFile:] at /Users/xxx/Documents/gitdepot/MMAutomation/ProofProcessor.m:989 #22 0x0000000100aa3fd4 in -[ProofProcessor main] at /Users/xxx/Documents/gitdepot/MMAutomation/ProofProcessor.m:187 #23 0x0000000195fc0f0c in __NSOPERATION_IS_INVOKING_MAIN__ () #24 0x0000000195fc027c in -[NSOperation start] () #25 0x0000000195fbfff4 in __NSOPERATIONQUEUE_IS_STARTING_AN_OPERATION__ () #26 0x0000000195fbfee4 in __NSOQSchedule_f () #27 0x0000000100f78514 in _dispatch_call_block_and_release () #28 0x0000000100f952dc in _dispatch_client_callout () #29 0x0000000100f7c274 in _dispatch_continuation_pop () #30 0x0000000100fb5290 in _dispatch_async_redirect_invoke () #31 0x0000000100f8e30c in _dispatch_root_queue_drain () #32 0x0000000100f8ee2c in _dispatch_worker_thread2 () #33 0x000000010101b768 in _pthread_wqthread () Is any of that helpful?

(2) Redesign your approach such that you stop actually doing any “long-term" running. That's a no-go. Jobs just have to run until they are done. There are dozens if not hundreds of pieces of data that are built and used along the way. Some of them are hogs that will run for 3 hours. How isolated are each of these jobs? For example, is progress being routed back to another thread or is all of the work contained to that thread? All the work for each job is pretty much self-contained in its thread as far as the SBApplication goes. Each job gathers data from the network, generates one of more InDesign documents and saved the resulting files of various types. They all communicate back to other servers by various means (simple "I'm still working" heartbeats), communicate with main parent app and various objects in the app to show progress, all of which has been heavily stressed and show no signs of causing problems. Swift has wormed its way into this fairly old Cocoa app, mostly in the data access from networks. Just mentioned that in case that adds its own demons. I'll also throw out that we've always been plagued with the odd "no result was returned" from scripts, and they all return a value. Sometimes this is reproducible when running on our servers, but not nearly as much when I run the same job on my Mac using InDesign Desktop instead of InDesignServer. I can't tell if it's the Adobe app that's failing to sometimes return the result from the script it runs, or the SB/AE world that fails. Again, mentioned in case it raises a flag.

That's interesting about the difference between NSOperation and NSThread as far as Mach ports go. I watched the # ports in Activity Monitor as I ran a job, and it certainly doesn't climb as each job runs. It goes from initially in the 300s to the low 500s right when the job starts, and stays around there, even after the job ends, and then I run the same job 2 few more times without quitting. This app can run for days or weeks. It can process anywhere from a few to probably a couple hundred jobs a day. Yes, each job creates a new NSOperation and a new SBApplication, which are both destroyed when each job finishes. Each job can call into the SBApplication hundreds or thousands of times. The rate at which each script is run can be as fast as possible, given the speed at which InDesignServer will process each script. At times there is barely any application code going on between each script. (E.g. ask InDesign for the range of some text, tell InDesign to do something with that range of text, tell InDesign to replace that range of text, etc, where each of those is a separate call to the doScript:language:withArguments:undoMode:undoName: method from InDesign's ScriptingBridge header file). I've added a 3rd crash log to the bug report, if it helps.

In your System Log post, this part has me confused: Console supports viewing log entries in a specific timeframe. By default it shows the last 5 minutes. To change this, select an item in the Showing popup menu in the pane divider. If you have a specific time range of interest, select Custom, enter that range, and click Apply. I'm not finding this pane divider popup, not as a visible control or as a contextual menu. Which pane divider? The Mac I'm looking on right now is sing macOS 26.3. My work one (not booted yet, but the one experiencing the problem for this thread) is 15.something.

I spent all day yesterday trying to make the error occur, but had no luck. Of course, when we need to get a job out the door for a customer, it pops up all the time.

Thanks, Kevin. I've entered FB21953216 with 2 crash logs attached. Both show multiple threads calling SB (job thread names begin with "ProofProcessor"). One has 3 jobs and the other has 4. Our app can run up to 40 jobs concurrently, but rarely get more than half a dozen, usually just a few. Each job can run a unique instance of InDesignServer. Our app runs "forever". Before moving to ScriptingBridge, we did run into the problem of only being able to run one script at a time from the main thread, so we added an external app and each job launched one of those to run the scripts. I don't recall the exact security changes nor in which OS we found that a change to ScriptingBridge was needed. A different engineer handled that change.

Hoo boy, making a sample app might be tricky. I'll find time to see if it's possible. Is there any way to know if the error is coming from OSA/SB or if InDesign is doing something goofy that would cause that error to be returned?

I submitted FB5703360 in 2019 (which was created radar). Since then I've also reported these for legacyScreenSavers: FB12086240 which deals with ScreenSaverViews not being removed, so they hang around and keep running. FB13362403 which deals with legacyScreenSaver continuing to run even after it is supposedly stopped (this might be because of FB12086240). FB13444225 which deals with legacyScreenSaver making multiple views when it shouldn't. Do you suggest that I add a 2nd bug report requesting a new app extension technology API?

I went ahead and submitted FB17280866. I came here first to just see if I was trying to do something that UITextView is not capable of doing.

I have a pared down project I can post, however I found one thing, and I'm not sure if it's supposed to work this way or not. I'm guessing not. I'd expect this to work, and it does: Load the text view from storyboard. Editing is not active. Change the smartQuotesType (or any other attr). Activate editing. The correct setting of smartQuotesType is used. I'd expect this to work too, but it does not: Load the text view from storyboard. Editing is not active. Activate editing. Change the smartQuotesType (or any other attr). Typing will use the value it was set to prior to activating editing. I'd expect this to work in both cases, but only the first works: Load the text view from storyboard. Editing is not active. Change the smartQuotesType (or any other attr). Activate editing. The correct setting of smartQuotesType is used. Change the smartQuotesType (or any other attr). Typing will still use the value it was changed to prior to activating editing. If changing the attributes should work in all cases above, let me know and I'll post the project.

Ah, thanks for that bit of info. I hadn't seen the comment feature before and figured it was a new way of replying to a specific reply. Odd. So I'll add it to my ever-growing pile of unresolved bugs. Neato.

BTW, the review team wouldn't let me use the entitlement, even though it's the only way I've found to workaround the bug, so I disabled the feature to open the Spotlight window for now. Hopefully this will be fixed toot sweet so I can enable it again.

Although the web page for Code-level Support Request has a blurb that says DTS will be answering questions directly in these forums between May 30 through June 17, and "will not be reviewing private support requests". So does that mean I can submit a request, but it will be ignored until June 18?

That was next on my list, if nobody had an answer for me here. I've also reported this as a bug.