This topic was automatically generated from Slack. You can find the original thread here.
Kenny MacDermid : The TIMEOUT stack doesn’t seem very useful… am I missing somewhere that would have more info about what was going on at the time of the timeout? In this case I can guess it’s the axios http request, but I’m not sure how to figure out why this sometimes happens.
Dylan Sather (Pipedream) : just to confirm, does the timeout error appear below the HTTP request step, or at the top of your workflow?
Would you mind sharing your workflow with dylan@pipedream.com so I can take a look at how we might improve this specific case?
Also - were you aware you can increase the timeout limit for your workflow in your workflow’s settings?
Kenny MacDermid : In the list of events, and in the global error workflow
Kenny MacDermid : and yes to the timeout. It’s calling a third-party firebase function though, so it should easily finish in under 30s (and does most of the time)
Kenny MacDermid : The workflow is public (and super simple): Voip.ms - Pipedream
Dylan Sather (Pipedream) : thanks, if you don’t mind sharing, that’ll let me see the error observability for this specific event - I’d like to take a look to see what happened in this specific case.
Kenny MacDermid : ((on the off chance it helps, this is the thirdparty function code: https://github.com/michaelkourlas/voipms-sms-firebase/blob/master/functions/index.js ))
Dylan Sather (Pipedream) : does it make sense to increase the timeout to capture the cases where it might take a little longer?
Kenny MacDermid : umm… perhaps. I was also considering setting a timeout on the request and I see there’s a ‘retry’ package that exists
Kenny MacDermid : I can probably work around the issue in this case, but I’m curious how I would have known where the issue was in a larger workflow
Dylan Sather (Pipedream) : I might be able to help you pinpoint if you don’t mind sharing the workflow via the Share button in the top-right (I can see your code but not your event data).
Kenny MacDermid : oh, yes, I can do that, just sec
Kenny MacDermid : done. Sorry, I just figured you had an impersonate login
Dylan Sather (Pipedream) : we do but as a matter of trust I normally like to make sure it’s OK with you first, and this is a convenient mechanism to establish that. Thanks, taking a look
Kenny MacDermid : makes sense. Thanks!
Dylan Sather (Pipedream) : so if you click on the TIMEOUT event in the event inspector on the left, do you see that the timeout appears just below the Send HTTP request step? That stack can most certainly be improved since it throws from Pipedream-specific code, but the fact that the error shows up directly below that step is your signal that the error happened in that step. If you had other steps above that, you’d actually still see the data returned from those steps.
Note the “execution end” line just below the step, as well. If you had other steps below that, they’d show up greyed out to indicate the workflow never made it that far.
I agree it’s strange that you’re seeing timeouts given the average execution time, but we should just be waiting until the default execution limit (30 seconds) and throwing this error if the workflow is still running at that point. Do you have logs on your target cloud function that might indicate why it’s running long?
Kenny MacDermid : ah, okay, I didn’t put together that the location of the message mattered. That makes sense
Kenny MacDermid : and no, no logs on the other side. It’s not much function I’m just trying to proxy a webhook to it
Kenny MacDermid : I figure the <1s vs 5s is when Google has a cold-start on the function, but that’s just a guess. I think to start I’ll turn up the time and see if it replies eventually
Dylan Sather (Pipedream) : yeah in this case I think that makes sense. I’ll also raise a feature request to clarify the timeout error message and make it more obvious that the timeout occurred in that step.