When using an async resolver which uses the fetch method to access an external endpoint the running flow is immediately interrupted #42
Comments
|
Hi @andreadipalma, and thanks for reporting. The first "weird" thing that I've noticed in your code is that the resolver Also, it is a great idea for debugging to run the flow with the environment variable If it doesn't compromise your project's privacy, you can share your flow spec and debugging information (obtained with the Also, I leave you a couple general things to double check when the flow runs without executing one or more tasks:
|
|
Hi @danielduarte thank you for your great suggestions. I'm going through them and posting later the info. |
|
@danielduarte the following is the flow descriptor. I see a potential flaw with the return "results", I remember it was done to return multiple variables in one single json. On the other side, I have some doubt on how to set the environment with process.env since the code runs on the browser and I can't use the types/node library. Can I set the debug through a parameter when running the flowmanager instead? I did further test. I eliminated the "async" from the resolver class exec method and run another rank type not requiring asynchronous call. It completes the workflow correctly. If in the code below I just add async to exec and still use an sync_rank (so it is not an async call) the workflow exits without completing the last task. I'm further convinced it depends on the flow definition. The flow descriptor: |
|
Hi @andreadipalma, you can debug and see how the flow runs in the browser by doing this:
Once that is done, run your flows and you should see something like this: There you have the details about every executed task with its parameters and results. |
|
For the example in my previous comment, I've written this little piece of code where I tried to reproduce your issue, but I wasn't able to do so. I've created a simple resolver with Maybe you could try this example to check if it is an issue with the browser version, Flowed package version (which I'd recommend to use the latest), your bundler or any other component. Please let me know if you were able to see the debugging logs, and what you found. I'll be glad to help. <html>
<head>
<script src="https://cdn.jsdelivr.net/npm/flowed@latest/dist/lib/flowed.js" charset="utf-8"></script>
</head>
<body>
<script>
// First of all:
// In order to see debug logs, open the browser developer console and run
// localStorage.debug = 'flowed:*'
// Also, if you use Chrome (or other Chromium-based browser such as Brave, Edge, etc.),
// please enable the Verbose level in the developer tools.
// The flow specification
const flow = {
tasks: {
T1: {
provides: ['a'],
resolver: {
name: 'r1',
results: {
a: 'a'
}
}
}
}
};
const params = {};
const expectedResults = ['a'];
class R1 {
async exec() {
const timerPromise = new Promise((resolve, reject) => {
// Wait for 2 secs and resolve the promise
setTimeout(() => {
resolve({ a: '123456' })
}, 2000);
});
const results = await timerPromise;
return results;
}
}
const resolvers = {
r1: R1,
};
// Run the flow and log results
Flowed.FlowManager.run(flow, params, expectedResults, resolvers)
.then(results => console.log('results', results));
</script>
</body>
</html> |
|
Hi @danielduarte , The second test is from the case "with the async resolver". So it interrupts the execution and not arrives to the third component (Top). I see a warning message from the second component (the async component) that doesn't produce the expected output. Debugging it I see it produces the output but at that point the flow of execution is lost somewhere. I've also made the modification/simplifications to the output value in the resolver as suggested. |
|
Hi again @andreadipalma, There I see a couple details to check: First, it seems like the flow specs in these cases are different: in the first case the resolver And second detail to check, in the second test the logs show that the resolver doesn't return any value, which is the reason why the next task in the flow (Top) is not executed. From 1st case (one result returned, required by "Top" task): flowed.js:1277 flowed:flow [1] ✓ Finished task 'TagRank', results: Array(1)0: var_adpnode[81339727-0140-49f8-a2b8-7be2f611245c]out_0: [][[Prototype]]: Objectlength: 1[[Prototype]]: Array(0) +1msFrom 2nd case (no results returned, so no dependent task executed): flowed.js:1277 flowed:flow [3] ✓ Finished task 'ContentRank', results: Array(1)0: {}[[Prototype]]: Objectlength: 1[[Prototype]]: Array(0) +32sSo, you'd need to make sure the required value (or a promise that resolves to it) is returned. I hope my comment helps. And please let me know if I can help with further debugging. |
|
@danielduarte thank you so much for your time and the helpful insights, really appreciated! I've double checked the point 1 about the different names, and tested again with the same name ... apparently I just captured the flows after some modifications including the name of the task (don't ask me why :-) but don't seem to sort any effect. I'm starting to think that your point on the transpiler could be involved. The following are my configurations if you see something strange could help me. I'm doing also a further step to run the same logic on a node server based component (so no browser involved). Let you know. |
|
Hi @danielduarte |
|
Hi @andreadipalma, |
When using an async resolver which uses the fetch method to access an external endpoint the running flow is immediately interrupted and returns the control to the caller function without completing the tasks.
Without the async resolver the workflow completes correctly, I suspect I'm doing some mistake with await async into the chain of function calls but really struggling to find where it could be.
The text was updated successfully, but these errors were encountered: