This topic was automatically generated from Slack. You can find the original thread here.
Alex Lindgren : Is there a variable or workflow state that is scoped to one invocation of a workflow?
Dylan Sather (Pipedream) : Hi , I think there are a few ways you could approach this. Do you need to use the variable across steps? Do you need to mutate the variable across steps, or only set in one step and read in subsequent ones?
If you can give me more detail on your use case I bet we can figure out a solution
Dylan Sather (Pipedream) : The simplest solution would be to reset $checkpoint at the start of your workflow, so that it operates as a mutable variable for use in your invocation, but it’s cleared on the next invocation. Would that work?
Alex Lindgren : That might work - but it would be possible to have two requests getting processed at the same time?
Alex Lindgren : I am looking to mutate the variable across steps as you said.
Dylan Sather (Pipedream) : What workflow trigger are you using? When you’re using an event source as a trigger, we support serializing the execution of workflows (concurrency = 1) - https://pipedream.com/docs/workflows/events/concurrency-and-throttling/#managing-event-concurency
Alex Lindgren : I’m using HTTP API trigger. I’m looking to use Pipedream to create a mock API.
Alex Lindgren : Does concurrency and throttling work with HTTP API? If so, I think that will be fine 
Alex Lindgren : I guess not. UI has it greyed out
Dylan Sather (Pipedream) : Thanks. For some technical reasons (which we are hoping to address), you can’t use the HTTP API trigger and concurrent controls simultaneously.
Would you be able to combine the code you’re using into a single step, so that you can use a local variable in the step to maintain state? You may have seen that all Pipedream-developed actions are technically Node.js code, which can be copied into other steps. I realize it’s not ideal, but would that work?
Alex Lindgren : anyway, it may not be a big deal - it’ just for mocking API responses during development
Alex Lindgren : Yes, I can do it in one step, but the code will get bulky. How about using a dictionary value for $checkpoint with the key of steps.trigger.context.id? and someone cleanup at the end of the workflow.
Dylan Sather (Pipedream) : totally, $checkpoint can hold any value, so if you want to key off of that or another ID unique to your request, that totally works
Alex Lindgren : cool, I’ll give it a try! thanks!
Dylan Sather (Pipedream) : good solution
Alex Lindgren : Thanks. Pipedream is fun to work with – so flexible.
Giao Phan : you are right in that $checkpoint only have eventual consistency so concurrent responses will race to update it, but within the context of a single workflow run the values will be stable, they won’t update via other workflow requests running.