Hi everyone. I’m building an extension that does a lot of work in the background. Due to the amount of work the extension prompts a message during the process (once). It states that there are a significant number of tasks pending.
Does any one know more about this or to be more specific:
How can you track the number of pending tasks?
What is the threshold for displaying this message?
How are these tasks stacked? I’m chaining a lot of tasks so there should not be many tasks running simultaniously.
Hi! What are these tasks related to? Javascript (Vanilla), React, Photoshop scipting, pixel-based analysis, file exchange ?
It will also matter how you are “chaining” your tasks together, using UXP batchPlay.
You might want to fractionize your code and try to identify what sections trig an error.
Typically, you’d get this if your code would by trapped in an ‘endless loop’, or a in a ‘Call Hell’.
Or if you have a slider that ‘talks’ to Photoshop and you’re reading and sending its value in real time…
About 90% of the tasks are related to photoshop (renaming folders, merging groups, moving folders, etc). The other 10% are some HTTPRequests.
For almost all tasks I’m using UXP batchPlay. And most of the times I’m waiting for one batchPlay to finish before I start the other batchPlay.
Currently there is one method that runs through all the documents and performs tasks. As a result that one method will take a very long time to perform. As it is waiting for all those UXP batchPlay’s to finish. Maybe that is the culprit.
Do you mean the Debugger in the UXP Developer Tool? If so, yes. But it doesn’t show any errors before or after the alert. When I close the dialog everything runs fine.
Is there any other way you would advice to debug this? Looking at the message I was kinda hoping that I could somehow see which tasks are pending. To determine why the message is shown. But if I understand correctly it is more of a generic message.
I remember that I had to break down several extra-long series of UXP calls into smaller sections, to identify which section breaks the code. Nesting/linking batchPlay can be quite tricky.
@Jarda@Pierre_G The problem was indeed due toe a very large stack of asynchronous batchPlay calls. Splitting these calls into chunks of 10/15 solved the issue. Thanks for your thoughts!
Thanks!