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
To recap the desired behavior of the inspector view:
When an admin accesses the inspector with a run loaded (as I do in the video) they're most likely debugging and will want to add console.log statements and re-run the work order multiple times from whatever step they're on.
Keep a close eye on the buttons in the bottom right corner... there are two of them. A "primary action button" (which in this video is supposed to "Rerun from here") and a "save" button (which has a helpful red-dot-indicator that will tell us if the job code has been saved).
Pressing Cntrl-S/⌘-S will save the job code.
Pressing Cntrl-Enter/⌘-Enter will press the primary action button. (In this case, that should be to "Rerun from here".)
There is also a "secondary action button" that can be reached via the split-button-select-list or by pressing Cntrl-Shift-Enter but that button is not pressed in this video. The secondary action would create a new work order, rather than only creating a new run for the existing work order.
Try to get a sense for what I'm doing here... I want to rerun this work order lots of times while I'm debugging and modifying the job code... all to try to eventually process this input dataclip (in this case, a Stripe transaction) properly. I'd like to keep running this thing dozens of times after making small adjustments, and eventually see a successful run. When that's done, I'll click back to the history view and see that this work order is in a "success" state, even if there are two dozen runs (previously called attempts) associated with it.
The bug I'm seeing here is three-fold:
In this video it sometimes appears that the job code is not saved when I press/click "Rerun from here". This is not good. We always want to "save and run" the job rather than running it without saving.
In this video we also see that despite always clicking/pressing "Rerun from here" a new work order gets generated a few times. I thought this might be happening when the job code was edited, but it seems to be less predictable than that.
EDIT: After some more digging, it appears that at some point in this video a new (duplicate) dataclip was generated. That shouldn't be happening and feels linked to the duplicate work order.
The text was updated successfully, but these errors were encountered:
@elias-ba , not specifically assigning you here in case someone else wants to pick this up first, but will certainly need your thoughts on the above! (and if you get to this first please do take it up. i'd suggest pairing with another programmer to talk through the current logic as it's fairly complicated and getting another review would be valuable.)
@taylordowns2000I think it's wrong label this as a bug. At the moment, the concept of retying means taking the previous runs input dataclip and retrying with it. When you edit a dataclip, that's essentially a new workorder
Check out this video: https://www.loom.com/share/0926d3aa804745a7b6614cfe34fcb088
To recap the desired behavior of the inspector view:
console.log
statements and re-run the work order multiple times from whatever step they're on.Cntrl-S
/⌘-S
will save the job code.Cntrl-Enter
/⌘-Enter
will press the primary action button. (In this case, that should be to "Rerun from here".)Cntrl-Shift-Enter
but that button is not pressed in this video. The secondary action would create a new work order, rather than only creating a new run for the existing work order.The bug I'm seeing here is three-fold:
The text was updated successfully, but these errors were encountered: