[tink-worker] Use workflowID instead of workerID in getWorkflowData #604
Conversation
|
/assign @micahhausler @jacobweinstock |
Codecov Report
@@ Coverage Diff @@
## main #604 +/- ##
=======================================
Coverage 45.96% 45.96%
=======================================
Files 56 56
Lines 3283 3283
=======================================
Hits 1509 1509
Misses 1684 1684
Partials 90 90
Continue to review full report at Codecov.
|
| @@ -471,7 +471,7 @@ func (w *Worker) getWorkflowData(ctx context.Context, workflowID string) { | |||
| } | |||
|
|
|||
| if len(res.GetData()) != 0 { | |||
| wfDir := filepath.Join(w.dataDir, w.workerID) | |||
| wfDir := filepath.Join(w.dataDir, workflowID) | |||
There was a problem hiding this comment.
how do we know these are the same values?
There was a problem hiding this comment.
All other places where we are creating the filepath for the data directory, we are using workflowID.
See lines 317 and 498 in this file. Without this change, tink-worker exits pre-maturely trying to access a directory that doesn't exist (created using the workerID instead of the workflowID).
|
@Mergifyio refresh |
✅ Pull request refreshed |
|
Thanks 🌮👍 |
Description
All other workflow data operations in tink-worker are using workflowID, this aligns getWorkflowData to use the same convention.
Why is this needed
This was causing tink-worker to fail to successfully run through workflows complaining that it couldn't open the right data file for tracking the workflow.
How Has This Been Tested?
Tested this locally using the sandbox configured to use the latest published components, and a version of tink-worker that I had build and pushed to a registry that I control.
How are existing users impacted? What migration steps/scripts do we need?
No existing users should be impacted, since the issue does not exist in the previous sandbox release.