How do I trigger a cron scheduler workflow multiple times throughout the day?

This topic was automatically generated from Slack. You can find the original thread here.

Kyle Schiess : Say I want a single workflow to run at multiple hours throughout the day.

Would it be better to have multiple workflows that trigger at each hour, or one workflow that has a CRON argument running a main function at every hour?

Will I be running up limits with the second option?

Tod Sacerdoti : In general, the first option is preferred and we are moving towards a model where the metric that matters will be workflow invocations. So, the less invocations you have, the better from an avoiding limits perspective.

Dylan Sather (Pipedream) : I’d recommend using a single workflow, since cron syntax should be expressive enough to handle use cases where you need to run a workflow at only specific hours. You can comma-separate a list of hours, for example:

0 4,5,6 ** ** **  // Run at 4, 5, and 6am

a range:

0 4-10 ** ** **  // Run at 4 - 10

or a frequency:

0 **/3 ** ** ** // Every 3 hours

Hi

I’m not able to set my CRON triggers at all, it always defaults back to run on an hourly basis, which is a shame since I’m looking to have it fewer times over the day than every hour. It doesn’t matter what I select or the interval I set it always are saved as a run every hour… Bug or feature for Free Plan?

Hi @anon4261531

First off, welcome to the Pipedream community. Happy to have you!

Free accounts have the same functionality as paid plans, it’s just a difference in invocation limits.

Sounds like you’re hitting a bug.

Would it be possible for you to share the network request that’s being made from your browser the Pipedream GraphQL API at the time you try to update the timer? The “copy as cURL” output would be super helpful.

We’ve been unable to reproduce this bug with different browsers.

Thanks for your quick response!
I’m reproducing it still (I believe) and this is what I can get from my Chrome Inspector, I select something under the CRON selection like the screenshot below, and hit Continue…


This comes up in the Inspector…Status 200 (ping);

https://rum-http-intake.logs.datadoghq.com/v1/input/pubcec5577782e914e650311489efb745ed?ddsource=browser&ddtags=sdk_version%3A3.6.6%2Cenv%3Aproduction%2Cservice%3Afrontend-next%2Cversion%3A6c48c56bf0f9c32e9791674b56fbd12ad5be99d4&batch_time=1646670151565

Let me know if you need additional information from me or my Inspector…

After hitting the Continue button in the earlier posts screenshot
this comes up in the UI

But when hitting the Configure tab again it shows the following (back to square one).

Or is it here it goes wrong, maybe I should just leave it and not go to the configure view again, it seems to default back to the Custom interval set to 1 hour…

Hi @anon4261531 ,

Thanks but unfortunately that’s an API call to Datadog, a logging provider.

Here’s how you can copy the API request that’s been sent to Pipedream to save your timer setttings:

Many thanks, thats what I’ve done actually adding the latest try with all the network activity coming from hitting the Continue button after doing any change on the interval f.e.

Seems I’m getting no graphQL actions at all only the ones seen on the screenshot

However if I go to my list of workflows and hit the EDIT button for the Trigger on the selected workflow the following graphQL requests occurs in the inspector

https://api.pipedream.com/graphql?operationName=pipeline&variables={"id"%3A"p_n1CJwLW"%2C"withCheckpoint"%3Atrue%2C"withCollaborators"%3Atrue}&extensions={"persistedQuery"%3A{"sha256Hash"%3A"25009617a8bcb2dfb42fbb33f5d39877d55e35153a265c9e4af4ece872796b7f"%2C"version"%3A1}}

https://api.pipedream.com/graphql?operationName=workflow&variables={"id"%3A"p_n1CJwLW"}&extensions={"persistedQuery"%3A{"sha256Hash"%3A"f75cc4800857de5ce1362c29220ee375fc33ea000d158aba96bfef74434c8392"%2C"version"%3A1}}

Also some additional screenshot, after selecting CRON Expressions and hit the Test button…
Please note it still shows 3600s in the Exports steps.trigger > event > interval.seconds regardless of what I select as my CRON expression…

Also what the inspector reveals meanwhile…

Hi @anon4261531

We’re getting closer! That’s definitely the right API host (https://api.pipedream.com/graphql)

However unfortunately without the whole request copied as a cURL command, our engineers are not going to be able to reproduce the bug to fix it.

Here’s how to copy the request as a cURL command:

  1. Right click on the graphql request in the Chrome Network Panel
  2. Hover over Copy
  3. Left click on Copy as cURL

I’m getting several graphQL queries,

Which one or ones should you like to have as cURL copies?

Screenshot 2022-03-07 182435

Maybe I can just allow your support to edit/access my workflow? :slight_smile:

Hi @anon4261531

Unfortunately this bug has been elusive when I’ve opened up other workflows that reportedly have this problem.

There should be 1 or 2 graphql requests happening right after you click Continue after selecting a new schedule on the timer component.

Clearing the network history is super helpful to narrow down exactly which graphql requests fire when you make that change:

You can share this workflow with support under the workflow settings, and I can try to reproduce but unfortunately that’s not been the case so far.

Unfortunately it does not create any graphQL requests at all… so I imagine this is where the problem originates… there are only several t?client=ui requests to api.pipedream.com/a

Nothing else…as seen on

1 Like

After deleting the trigger completely and recreating it I imagine this is the graphQL sequence triggered

curl “https://api.pipedream.com/graphql?operationName=workflow&variables=^%^7B^%^22id^%^22^%^3A^%^22p_n1CJwLW^%^22^%^7D&extensions=^%^7B^%^22persistedQuery^%^22^%^3A^%^7B^%^22sha256Hash^%^22^%^3A^%^22f75cc4800857de5ce1362c29220ee375fc33ea000d158aba96bfef74434c8392^%^22^%^2C^%^22version^%^22^%^3A1^%^7D^%^7D” ^
-H “authority: api.pipedream.com” ^
-H “pragma: no-cache” ^
-H “cache-control: no-cache” ^
-H “sec-ch-ua: ^^” Not A;Brand^^";v=^^“99^^”, ^^“Chromium^^”;v=^^“99^^”, ^^“Google Chrome^^”;v=^^“99^^”" ^
-H “dnt: 1” ^
-H “sec-ch-ua-mobile: ?0” ^
-H “user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36” ^
-H “sec-ch-ua-platform: ^^“Windows^^”” ^
-H “accept: /” ^
-H “origin: (cant include more than 1 URL it seems)” ^
-H “sec-fetch-site: same-site” ^
-H “sec-fetch-mode: cors” ^
-H “sec-fetch-dest: empty” ^
-H “referer: (censored)/build” ^
-H “accept-language: sv-SE,sv;q=0.9,en-US;q=0.8,en;q=0.7,de;q=0.6” ^
-H “cookie: ajs_anonymous_id=e2d9a7ff-4541-4f5a-8a72-582255ab6724; _gcl_au=1.1.1250633388.1646676802; pdsid=1e2baa9bdb77562f8267a333da66c807; ajs_user_id=u_0ZhedLO” ^
–compressed

Problem still remains though…

Thanks @anon4261531 I think that must be it.

It makes sense, the graphql request is never made, so when you refresh the page the change is not reflected because it was never sent in the first place.

Updating our internal tracking with this information.

It has to be some kind of bug at the browser code level, the only workaround for now is to try another device/browser or maybe a new account.

1 Like

A new account and using Edge browser instead of Chrome made the Cron Trigger functional… thx hope you solve the bug anyway! :slight_smile: