Experiencing an issue today and can't work out if its me, or a bug.
All of a sudden the test parameters in workflows for the startTrigger are no longer working, when I connect a block to the startTrigger and check the inputs, startTrigger.data is greyed out.
I checked an existing workflow that had example data I know worked already placed within, as soon as I copied the contents and repasted it back in, it broke. So its not an issue with one, or a new, workflow and I know my test data is good.
Using this workflow with parameters passed in from a retool UI page works as expected, so its not like the actual startTrigger.data is broke, only with the test parameters.
I managed to reproduce, and will be filing an incident with the team to address this.
From testing, this seems to only affect development, specifically individual block runs.
Workaround
If you run the workflow as whole using the "Run" button in the top right, the workflow should still work, so I would expect existing workflows triggered via webhook etc should still work as expected. Hopefully running the workflow as a whole can unblock folks until we can hotfix/roll back cloud.
We’ve been running into the same issue with test parameters being broken. startTrigger.data is "undefined", and even previously working test data stopped working. Definitely seems like something is off.
Thanks for jumping on this and forwarding to the relevant team.
My workflows seem to run okay and pass the startTrigger.data if its handed a web hook or called from a Retool UI page, so existing flows are fine for me.
However I am trying to develop a new flow and don't dare try and pass information without testing what is contained in the startTrigger by using the placeholder info, as it could be quite costly (data goes out to an external process).
Hopefully it is a quick fix on your side, as it's stalling my development currently.
Hey @Troy_Offer unless I'm misunderstanding, you should still be able to continue developing:
You should be able to remove any links to blocks which you don't want to run later down the WF (which may incur costs),
Re-deploy the workflow,
Re-trigger the webhook with just the JS blocks etc to print and confirm startTrigger data format is correct (check the workflow run logs to make sure everything looks good)
If all good, reconnect the later blocks, re-deploy, and run the whole workflow
Yes, I could do that - if I had existing data being passed in.
Currently I am developing a flow from scratch that has nothing being passed in from elsewhere. Therefore the test parameters are how I'm starting the process of working out what I want to pass in and how the process I'm building will handle the data.
I don't really want to have to spend time putting together a UI just to pass data into the new flow because the test parameters feature is broken.
So its kind of inconvenient on both sides of the flow unfortunately.
@Troy_Offer Just to clarify, the test parameters do still work if you run the workflow via the "Run" button , in my screenshot above you can see the backend run works!
Sorry for the confusion, assumed you were triggering like that given your comment:
My workflows seem to run okay and pass the startTrigger.data if its handed a web hook or called from a Retool UI page, so existing flows are fine for me.
Hey @Elliott_Dobbs! I'm having trouble reproducing the issue on our end, this functionality seems to be working as expected -- could you share any steps for a repro?
To be honest, I have changed nothing on our Workflows that broke the last time, but I started getting the same error again where blocks are seeing startTrigger as undefined.
Similarly, it is only for the workflow runs that are triggered by a schedule. I am able to run them manually.
I have a workflow that runs hourly, but looks like the error began yesterday (2-12) at 5:00 PM CST. Every scheduled workflow since then has failed with the same error "TypeError: Cannot read properties of undefined" when it tried to read startTrigger.data.
I've been dealing with similar issues on workflows with schedule triggers, and workflows triggered by other workflows - all code works fine in the editor and when run manually via the "Run" button, but scheduled runs cannot read startTrigger.data reliably.
We first observed the issue late on Monday the 10th / early Tuesday the 11th. It went away for a bit and we observed zero instances of the issue until late on Wednesday the 12th, and it's remained a persistent problem since then. Most of the impacted workflows have not been updated in any way for months before the issues began.
Logs for impacted workflow runs show "undefined" in the "Data" tab when the startTrigger block is selected. I added a JS code block immediately after startTrigger in some impacted workflows to inspect startTrigger before trying to perform any real work, so I could at least throw an error and end the run gracefully.
Many of our scheduled workflows read some parameters from their startTrigger, then pass those parameters into other workflows, impacted runs show undefined for the entire startTrigger object on both the parent and child workflows.
This is impacting a few dozen workflows we have running on daily schedules, the issues are intermittent but widespread and frequent enough to be a real problem. I've tried editing the contents of startTrigger then redeploying, turning off the scheduled trigger and turning it back on, etc. but so far I've not confirmed a reliable fix.
I can provide specific workflow and run ID's privately upon request.
Same issue here. The workflow runs successfully if triggered manually via "Run", but returns an error ("TypeError: Cannot read properties of undefined") if triggered via cron.
