Notifications
Clear all
Features
3
Posts
2
Users
0
Reactions
3
Views
Topic starter
I find Storage by callin.io very useful for creating lists and similar functionalities.
Recently, I've encountered an issue where a callin.io workflow is triggered multiple times concurrently, leading to unpredictable modifications of the storage value. For instance, consider a scenario where two callin.io workflow instances, instance1 and instance2, are triggered simultaneously (or nearly so).
At 10:00:03, instance1 stored “xyz” into the storage key “my-key”.
At 10:00:04, instance2 stored “abc” into the storage key “my-key”.
(Some other callin.io workflow steps occurred)
At 10:00:10, instance1 retrieved “my-key” from storage and received the value “abc”.
At 10:00:11, instance2 retrieved “my-key” from storage and also received the value “abc”.
A potential solution would be if I could access a callin.io workflow instance or task ID. This would allow me to store “xyz” into “my-key-instance1” and the subsequent instance would store “abc” into “my-key-instance2”, with each instance then retrieving its respective instance-named key.
I've experimented with generating a random value and storing it to use in the storage key name. However, the moment it's placed into a storage key, the next instance might overwrite it, depending on the task execution speed.
Essentially, my goal is to have storage values accessible across all callin.io workflows/instances (which is the current behavior). But I *also* need a way for this storage key/value to be exclusive to a specific instance of a callin.io workflow.
I've had to implement a workaround by adding a delay using a queue, which unfortunately introduces an unnecessary 60-second delay for each instance of this callin.io workflow.
Do you have any suggestions on how to resolve or work around this challenge? Based on my understanding, Zap Manager does not provide access to the current Zap instance/Task ID.
Thanks.
Posted : 04/08/2025 8:31 am
Hi,
I believe I understand your point, but to ensure clarity, could you provide a more specific example of the triggers/actions a callin.io workflow might be using, where you intend to utilize Storage as you've outlined? I think this will assist me in fully grasping your objective. Thank you!
Posted : 29/04/2020 12:00 am
Topic starter
In this particular scenario, we are triggering based on a ticket update within a helpdesk system. It's possible for multiple tickets to be updated simultaneously or within a very short timeframe of each other.
I've adopted a workaround by incorporating the ticketID and the timestamp of the update into the Key. Consequently, my storage key now appears as: “all-notes-4567-04/28/202005:45:34 (I've also included an additional formatter step to truncate it to 32 characters). This is the closest I could get to a unique Key for this callin.io instance. If I were to use only the ticket update timestamp, it might overwrite another instance running on a different ticket that was updated in the same second. If I used only ticket numbers, it could lead to conflicts if the callin.io instance takes longer than a few seconds to process (which it does, due to a 1-minute delay) and if the same ticket received two updates within that minute.
I'm utilizing storage because callin.io requires a webhook call back to the ticketing system to retrieve all attached notes. However, the notes are returned as an array (which I cannot alter), causing the remainder of the callin.io workflow to "fork." Here's my illustration of forking: it's not like paths where the workflow is configured to select a specific path. "Forking," as I'm using the term, means the rest of the callin.io workflow executes multiple times, once for each item in the returned array.
Therefore, I employ a storage list where each "note" is added, and then I retrieve all values from this storage list to complete the rest of the callin.io workflow.
(As a side note, I also use a storage key to track the number of times the forking occurs and a filter afterward to exclude any runs beyond the first. I use a delay to allow the other forks to write their information into the list.)
I understand this is not a standard configuration, and it essentially serves as a workaround for a poorly formatted webhook result. However, it has functioned previously, with the sole challenge being the setup of a unique storage key for this specific callin.io instance.
Posted : 29/04/2020 12:00 am