How to get SC to return success regardless of Exec status?

Feature Request
,
#1

I have an SC with Exec that sends email. Can I get my SC to return success without considering the status of the Exec? The problem I have is the email execution will take a bit longer and that affects the loading of the SC. I used to use separate SC for email (on success) but I’ve changed my workflow with Exec.

#2

Use as last step a response action with a 2xx code.

#3

How do you mean? If I put the response as the last step, the SC will still wait for the Exec, if I put it before the Exec, the SC will skip it at all.
2021-02-15

#4

Sorry now I get you. You don’t want to wait for the exec step to finish.
I though you just wanted to force a 200 response. I’ve never tried something like that but I don’t think you can . By designs all steps run sequentially.

It would be nice however to set a flag in the exec so the next step is ran without waiting.

#5

Alright. I hope there’s workaround for it. Thanks.

#6

Thanks an interesting requirement. Would be great to have in Wappler. Maybe requires a FR?

#7

Yes agree!

#8
#9

This will not work, even is we would not stop the script at the response and do the exec the response will only be returned after the whole script is executing because it is all buffered.

1 Like
#10

Is there feasibility to implement something like onsuccess then run library, or other api, completely from server side? When added it should treat the Exec as different/separate process.

#11

As a workaround:

  1. you can probably configure another server action with the steps being used in exec
  2. Let this main SA work as normal, remove exec from here
  3. On success event of main SA, just call the other SA. It won’t block the client ui… And you don’t necessarily have to show any indicator that its running either.

The better option here would have been the ability to optionally run steps like api call and exec (or everything) as “background”, but just to make changes for exec, does not make much sense to me.

#12

I think that how I used to do. I still believe there’s way to completely do this from SC though. Since my main issue is with email execution, I’m gonna try using insert query, then, using scheduler from server side to execute mailer base on the query with status not sent.

#13

That is definitely a better way to send out emails in my opinion. We have a similar system a project where emails get queued and then sent every few seconds.

1 Like
#14

I did this. I believe the step was right except scheduler seems not work with mailer. Got this error:

 (node:6040) UnhandledPromiseRejectionWarning: TypeError: this.req.get is not a function
    at App.send (C:\laragon\www\nodejs\site\lib\modules\mail.js:74:41)
    at App._exec (C:\laragon\www\nodejs\site\lib\core\app.js:429:57)
    at App._exec (C:\laragon\www\nodejs\site\lib\core\app.js:400:28)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async App.exec (C:\laragon\www\nodejs\site\lib\core\app.js:369:9)
    at async App.exec (C:\laragon\www\nodejs\site\lib\modules\core.js:169:13)
    at async App._exec (C:\laragon\www\nodejs\site\lib\core\app.js:429:30)
    at async App._exec (C:\laragon\www\nodejs\site\lib\core\app.js:400:17)
    at async App.exec (C:\laragon\www\nodejs\site\lib\core\app.js:369:9)
    at async App.repeat (C:\laragon\www\nodejs\site\lib\modules\core.js:72:17)
(node:6040) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 10)

I’ve tested few scenario, within repeat, using single query, with Exec, directly create mailer there, with Try and Catch, all consistently returned this error when there’s email in the step. Other step like update works without issue.

The steps:

  1. Query status == 0
  2. Email based on Query
  3. Update status = 1

May I have confirmation here if scheduler does support mailer component of not. Or which step I might did wrongly. I need assistance on this @patrick.

And @sid if you have spare time feel free to test it as well. :pray:

Update: Findings after more tests:

  • mail delivers when body is set to static and not html.
    “body”: “{{query_mailer_list.mail_body}}”,
    “contentType”: “html”
  • mail with Exec > Library (with param) doesn’t work (error above)

So probably has something to do with existing bugs, I dunno…

Update#2:
Indeed, there’s no issue with Exec. After I changed the Mail Send setting in the Library > Format: Text the email goes through. So the culprit here is Email Format: HTML.

#15

I saw this with one of our clients - when they selected a HTML type or HTML file, the mailer would just crash. But, I could not post this because I could not find time to verify it on my system. Their project has other system specific issues too.

If this is actually a bug, it would be great to have it fixed. Can you try using a file as HTML source too?

#16

Tried on latest the version ( 3.7.7). Doesn’t work. Will report the bug later.

1 Like