You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Placing an iterator inside a parallel fork/join produced a bogus failed to resolve workflow step dependencies error and the workflow couldn't be saved or run. Iterator conversion required its next and exit children in the graph first; join gateway required all parents in the graph first. When an iterator's exit path led to a join gateway, they formed a circular dependency and the resolution loop stalled.
After an error handler was registered, author-chosen variables like errorMessage / errStep became unavailable to downstream steps the moment any non-erroring step ran between the handler registration and the actual error. Manifested as "works initially, stops working after some time/uses", clustered in subworkflows and inside exclusive/inclusive gateways.
Any variable set by a step inside a parallel branch could silently vanish at the join if that branch wasn't paths[0]. Authors hit this as "HTTP Template can't find the variable the Base64 step produced" and worked around it by moving affected steps out of parallel sections entirely.
Previously, when makeGraph stalled it emitted a single "failed to resolve workflow step dependencies" error attached to whatever step happened to be iterated last. The user couldn't tell which step was stuck or why
Placing an iterator inside a parallel fork/join produced a bogus failed to resolve workflow step dependencies error and the workflow couldn't be saved or run. Iterator conversion required its next and exit children in the graph first; join gateway required all parents in the graph first. When an iterator's exit path led to a join gateway, they formed a circular dependency and the resolution loop stalled.
After an error handler was registered, author-chosen variables like errorMessage / errStep became unavailable to downstream steps the moment any non-erroring step ran between the handler registration and the actual error. Manifested as "works initially, stops working after some time/uses", clustered in subworkflows and inside exclusive/inclusive gateways.
Any variable set by a step inside a parallel branch could silently vanish at the join if that branch wasn't paths[0]. Authors hit this as "HTTP Template can't find the variable the Base64 step produced" and worked around it by moving affected steps out of parallel sections entirely.
Previously, when makeGraph stalled it emitted a single "failed to resolve workflow step dependencies" error attached to whatever step happened to be iterated last. The user couldn't tell which step was stuck or why