I am launching page https://www.nasdaq.com/ . After that I am also waiting for 5 sec to load the page. After this I want to check whether the page exist or not, or gets loaded or not then throw the exception. So how and when to use exception handling in this scenario. see the image attached. I tried putting recover, resume, exception stage on launch stage as well as on wait stage. But I dont know where to put the exception.
1st of all, don't use arbitrary (fixed) wait stages until it's completely necessary. Use intelligent wait stages instead, which means wait for something to happen and then proceed or throw an exception if it times out. In your case, you can use intelligent wait stage for example to check if the website has been loaded.
When it comes to throwing an exception, in your case I would just simply launch, then wait for the document to be loaded and throw an exception if it times out. See below diagram.
Also, I would leave retry logic (recover - resume) for the process layer. Object should ideally contain small reusable actions and no business logic, so decisions if and how many times to retry should be taken in the Process.
Related
with access to a trio.Nursery instance nursery, how may I print state of all nursery.child_tasks, specifically which have not yet exited?
I'm not understanding, reading docs & the trio NurseryManager code:
how "nested child" tasks might be relevant. I see [direct] children removed when a task completes with _child_finished(), but am not understanding use of _nested_child_finished().
the window of time between one task failing (raiseing), and all tasks completing. Being cooperative, I would expect to be able to find "active" tasks, in the window ~soon after one failure, with both states
"failed, exception captured"
and "running, has not handled Canceled yet"
"Nested child" is our internal name for "the block of code that's actually part of the parent task, that you typed inside the async with open_nursery():. This code runs a bit differently than a real child task, but it has similar semantics (the nursery won't exit until it exits, if it raises an exception it cancels the real child tasks and vice-versa, etc.), so that's why we call it that.
You're correct that there's a window of time between one task raiseing and other tasks completing. When a task raises then the other tasks get cancelled, but this means injecting trio.Cancelled exceptions, waiting for those exceptions to unwind, etc., so it might take some time. (You can tell check whether the nursery has been cancelled with nursery.cancel_scope.cancel_called.)
During this period, nursery.child_tasks will have only the tasks that are still running (i.e., still processing their cancellation). Currently Trio doesn't keep track of "failed tasks" – the nursery keeps a list of the exception objects themselves, so it can re-raise them, but it doesn't track which tasks those came from or anything, and there's currently no API to introspect the list of pending exceptions.
Zooming out: Trio's general philosophy is that when thinking about code organization, functions are more useful than tasks. So it really de-emphasizes tasks: outside of debugging/introspection/low-level-plumbing, you never encounter a "task object" or give a task a name. (See also Go's take on this.) Depending on what you're doing, you might find it helpful to step back and think if there's a better way to keep track of what operations you're doing and how they're progressing.
I am running a Rust app with Tokio in prod. In the last version i had a bug, and some requests caused my code to go into an infinite loop.
What happened is while the task that got into the loop was stuck, all the other task continue to work well and processing requests, that happened until the number of stalling tasks was high enough to cause my program to be unresponsive.
My problem is took a lot of time to our monitoring systems to identify that something go wrong. For example, the task that answer to Kubernetes' health check works well and I wasn't able to identify that I have stalled tasks in my system.
So my question is if there's a way to identify and alert in such cases?
If i could find way to define timeout on task, and if it's not return to the scheduler after X seconds/millis to mark the task as stalled, that will be a good enough solution for me.
Using tracing might be an option here: following issue 2655 every tokio task should have a span. Alongside tracing-futures this means you should get a tracing event every time a task is entered or suspended (see this example), by adding the relevant data (e.g. task id / request id / ...) you should then be able to feed this information to an analysis tool in order to know:
that a task is blocked (was resumed then never suspended again)
if you add your own spans, that a "userland" span was never exited / closed, which might mean it's stuck in a non-blocking loop (which is also an issue though somewhat less so)
I think that's about the extent of it: as noted by issue 2510, tokio doesn't yet use the tracing information it generates and so provide no "built-in" introspection facilities.
I'm facing an annoying issue in Blueprism a little help will be appreciated.
The error is when I run the task I have created in object studio directly in object studio it runs successfully but when I try to run the same task from process studio using action It throws an error. The application is launched but get this error. (Application is web-based.)
Internal: Failed to perform step 1 in Read Stage 'Reader1' on page 'Main' - No elements match the supplied query terms
this is Application Modeller Settings
Application Modeller
And this is how I call it in Process
Object Called in process
Action Properties
Wait Settings are following
When I try to highlight the link it does highlight it.
I think that after your Reader1 should be a decision if element was found or not and then you can proceed with log-in. But I'd check if the element you're spying is working correctly. Maybe try passing value of reader from object to process.
A process in BluePrism can have different speed of execution depending on the way you're running it.
If you're running application using "Step" function (hotkey F5), then BluePrism waits a long time between executing actions. A "Step above" (hotkey F10) is much faster, but the fastest possible speed of execution is from control room.
The delay from "Step", or "Step above" can be enough to make process work during the development. Once the process is moved to control room, then the delay is gone and sometimes the process might be running too fast. It can happen, that the BluePrism is trying to interact with the element that does not yet exist.
To make process work in control room, you need to have additional wait stages that will ensure that the process is not running ahead of the applications that are being automated. Whenever you're interacting with any element then you need to be sure that it exists.
i suspect that you're waiting for an element, but then you're trying to read a different one. It's important to wait for the exact element that you want to interact with, as elements can appear in an order, that can make your process crash.
I've the following case:
When the asynchronous processing of the thread is finished, an exception is thrown at line 15 with the following message: Transactions is not active.
Notice that I set the transaction timeout, because the error occurs only after several minutes of execution of the method "doAnything()" When execution take one or two minutes, the error does not occur. However, setting the timeout did not work.
Any idea?
Thanks.
This bean is illegal -- you cannot start a new thread. Doing so goes behind the back of the container and you lose your transaction management, security management and more.
See this answer for details on how transaction propagation works under the covers
See this answer for how you can use #Asynchronous instead of starting your own threads
Note, even with #Asynchronous you cannot have a transaction that spans multiple threads. There are no TransactionManagers out there that can support it and therefore the specs do not allow it.
I have a workflow, which creates a task and deletes it after the task is edited and its useful information acquired. I created a custom edit form for the task, so I have an SPLongOperation that I can use to stall the page. This is necessary, because if I don't stall the page in some fashion, the person will see the task in the task list for the minute moment before the workflow gets to delete the task, and that is bad. So some code to stall the page until the task is fully deleted is necessary.
I have currently implemented a solution for this, but I am unsatisfied with the approach. It basically is summed up to a while loop that calls SPList.GetItemById until it throws an error. Deliberately attempting to cause an error doesn't sit well with me, but I cannot think of a faster method for checking this. I'm looking for alternatives that would preferably work faster if not as fast, and preferably without relying on catching exceptions.
How about using an SPQuery to lookup the ID and if it doesn't find it then continue. This doesn't throw any exceptions.