feat: filter for running workspaces #4157
Conversation
presleyp
requested review from
BrunoQuaresma
and removed request for
a team
| id: "workspacesState", | ||
| on: { | ||
| GET_WORKSPACES: { | ||
| actions: "assignFilter", | ||
| target: "gettingWorkspaces", | ||
| target: ".gettingWorkspaces", | ||
| internal: false, |
There was a problem hiding this comment.
The vscode extension adds that automatically :/, it's just a more precise name of the state.
| }, | ||
| }), | ||
| }, | ||
| services: { | ||
| getWorkspaces: (context) => API.getWorkspaces(queryToFilter(context.filter)), | ||
| updateWorkspaceRefs: (context, event) => { |
There was a problem hiding this comment.
I think I can understand what is happening here but I would add a comment about the refsToKeep and what the ref.stop is doing. Also, do we need to make this a service since it does not run any async ops.
There was a problem hiding this comment.
Yeah, I made it a service because we don't want to do stop and send in an assign action, and it's okay in another action, but then it's harder to send data from one action to the next (which is by design, I think). I think I would need to save refsToKeep and newWorkspaces in context, and that felt like clutter.
|
I also question myself if I made a good decision by spawning refs inside of this machine. Unfortunately, managing the refs and keeping them in sync is very hard with the current XState tooling. |
presleyp
changed the title
|
@BrunoQuaresma I thought I had merged the part of this that you reviewed before, but I had some kind of mix-up, so feel free to skip the xservice part, it hasn't changed since you reviewed it. |
| AND CASE | ||
| WHEN @status :: text != '' THEN | ||
| CASE | ||
| WHEN @status = 'pending' THEN | ||
| latest_build.started_at IS NULL | ||
| WHEN @status = 'starting' THEN | ||
| latest_build.started_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.completed_at IS NULL AND | ||
| latest_build.updated_at - INTERVAL '30 seconds' < NOW() AND | ||
| latest_build.transition = 'start'::workspace_transition | ||
|
|
||
| WHEN @status = 'running' THEN | ||
| latest_build.completed_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.error IS NULL AND | ||
| latest_build.transition = 'start'::workspace_transition | ||
|
|
||
| WHEN @status = 'stopping' THEN | ||
| latest_build.started_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.completed_at IS NULL AND | ||
| latest_build.updated_at - INTERVAL '30 seconds' < NOW() AND | ||
| latest_build.transition = 'stop'::workspace_transition | ||
|
|
||
| WHEN @status = 'stopped' THEN | ||
| latest_build.completed_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.error IS NULL AND | ||
| latest_build.transition = 'stop'::workspace_transition | ||
|
|
||
| WHEN @status = 'failed' THEN | ||
| (latest_build.canceled_at IS NOT NULL AND | ||
| latest_build.error IS NOT NULL) OR | ||
| (latest_build.completed_at IS NOT NULL AND | ||
| latest_build.error IS NOT NULL) | ||
|
|
||
| WHEN @status = 'canceling' THEN | ||
| latest_build.canceled_at IS NOT NULL AND | ||
| latest_build.completed_at IS NULL | ||
|
|
||
| WHEN @status = 'canceled' THEN | ||
| latest_build.canceled_at IS NOT NULL AND | ||
| latest_build.completed_at IS NOT NULL | ||
|
|
||
| WHEN @status = 'deleted' THEN | ||
| latest_build.started_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.completed_at IS NOT NULL AND | ||
| latest_build.updated_at - INTERVAL '30 seconds' < NOW() AND | ||
| latest_build.transition = 'delete'::workspace_transition | ||
|
|
||
| WHEN @status = 'deleting' THEN | ||
| latest_build.completed_at IS NOT NULL AND | ||
| latest_build.canceled_at IS NULL AND | ||
| latest_build.error IS NULL AND | ||
| latest_build.transition = 'delete'::workspace_transition | ||
|
|
||
| ELSE | ||
| true | ||
| END | ||
| ELSE true | ||
| END |
There was a problem hiding this comment.
@coadler I'm curious why we went this route of deriving this in the sql instead of just adding a state field and keeping it up to date in the go code when we change something. Is it because it is difficult to constantly keep this state up to date because of the fact that the build can change state independently?
There was a problem hiding this comment.
While writing I thought that's something we could do to improve this, but I wasn't interested in doing it in this PR due to the possible consistency issues.
I meant to merge the xservice refactor alone but had some kind of branch mixup, so now it's all in one PR, and closes #3655
sendandstopinsideassign, so I broke what we have into two functions, a service and an action, to address that. Often, XState issues can be resolved by adding a new state. While I was there I realized we weren't using theidlestate, and are free to start right in withgettingWorkspaces, which means we don't need touseEffect.You can filter by any status but only Running is in the dropdown.
