i15-1: display the queue from the daq-queue-service#45
Conversation
There was a problem hiding this comment.
Looks like a great start, thank you. I think we should probably see if @zoharma and @douglaswinter have opinions too. Some comments in code. Additionally, my initial thoughts on the look/feel, feel free to spin into new issues/PR given the size of this PR already:
- Should: There's no feedback when we can't connect to the queue, it just says it's running
- Should: I don't really think ID is useful to be user facing
- Should: The pause will pause after the next task in the queue is finished, I think it would be good to rename it to make that more obvious
- Should: This PR includes stuff for the abort button, we should probably have the same button on the queue page (in fact maybe everywhere)
- Could: It would be nicer if the drag and drop was entirely disabled for the current/past tasks so its more obvious you can't do it
- Could: If there's nothing in the queue then having it saying it's running is a bit odd, maybe "Queue finished"?
- Could: I think some tooltips on the column headers would be good
- Nit: You can filter by the action column, this doesn't really make much sense
- Nit: Status is an enum but when you filter by it you put in a string, might be nicer if the filter was an enum
|
|
||
| export type TaskStatus = | ||
| | "Waiting" | ||
| | "Claimed" |
There was a problem hiding this comment.
How do I trigger a claimed state in the queue?
There was a problem hiding this comment.
This is leftover from before the queue refactor, I need to remove that type now as the correct one exists in generated/. Tasks can now only have the following status:
class Status(StrEnum):
QUEUED = "Queued"
IN_PROGRESS = "In progress"
COMPLETE = "Complete"
CANCELLED = "Cancelled"Blueapi calls can be claimed though. This represents the time when the worker has popped the call from the queue but blueapi hasn't started running it yet. A task's status is derived from the status of the blueapi calls it has produced, so both a claimed and in_progress blueapi call make its parent task in_progress.
class CallStatus(StrEnum):
WAITING = "Waiting" # Waiting in the queue
CLAIMED = "Claimed" # Claimed by the worker
IN_PROGRESS = "In progress" # In progress inside BlueAPI
SUCCESS = "Success" # Completed successfully
ERROR = "Error" # Error while trying to run| sampleId: string; | ||
| planRunning: string; | ||
| parameters: string; | ||
| // parameters: PlanParameters; |
There was a problem hiding this comment.
Should: Remove commented out code
| import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query"; | ||
|
|
||
| // const QUEUE_SOCKET: string = "/api/daq-queue"; | ||
| const QUEUE_SOCKET: string = "http://127.0.0.1:8001"; |
There was a problem hiding this comment.
Must: Can we have some way of generically configuring this so that it works for testing and prod
There was a problem hiding this comment.
Have added an env variable to toggle between these, which also turns mock service worker on/off.
| enableRowDragging: true, | ||
| enableSorting: false, | ||
| muiRowDragHandleProps: ({ table }) => ({ | ||
| onDragEnd: () => { |
There was a problem hiding this comment.
Should: I think some tests on the logic here would be good.
|
Two top-level comments/questions: 1) How does this view relate to the design in Figma? 2) Echoing Dom's comment, we need tests for this, both plain unit tests for your queries and logic, and RTL tests for the rendering. |
6a0c321 to
a839a06
Compare
|
It's getting iteratively closer to the figma design, but still some differences:
In the interest of getting this merged + deployed asap, so the scientists can have a play around with it, I can spin these into separate issues to fix in future? |
0b3f29c to
468ae62
Compare
|
I've now added some tests. I've put the remaining comments from @DominicOram in a new issue: #56 |
|
I'm adding all my comments, although some may be split to further issues and PRs:
Questions:
For later:
|
c0c0253 to
a9b726e
Compare
Yeah I'll look into displaying this more nicely, see #52
I think not, as I can't think of a case where you wouldn't want it to display in position order
This removes the task from the queue. Happy to rename it to something else, maybe |
DominicOram
left a comment
There was a problem hiding this comment.
Thanks, good work! I'm still trying to get my head around react but this looks good. Couple of comments in code, additionally when I try and display historic tasks when running in mock mode I get an error
| @@ -0,0 +1,9 @@ | |||
| { | |||
| "features": { | |||
There was a problem hiding this comment.
Should: Can you remove this and add to the .gitignore?
| import type { QueuedTasks } from "./tasks"; | ||
|
|
||
| const QUEUE_MODE = import.meta.env.VITE_QUEUE_MODE; | ||
| const QUEUE_SOCKET: string = |
There was a problem hiding this comment.
Should: Can you add a link into #59 to tidy this up
| @@ -0,0 +1,30 @@ | |||
| import type { TaskWithPosition } from "./generated"; | |||
|
|
|||
| // Temporary parameters to see if things work in the first instance | |||
There was a problem hiding this comment.
Should: Can you link to an issue describing what we need to do to make this less temporary?
There was a problem hiding this comment.
I don't think we need this now that I've generated typed from the queue API. I've deleted this
| enableSorting: false, | ||
| enableDensityToggle: false, | ||
| enableFullScreenToggle: false, | ||
| muiRowDragHandleProps: ({ row, table }) => { |
There was a problem hiding this comment.
Could: Would be nice to test some of this dragging but I suspect that's a PITA
There was a problem hiding this comment.
There's a test for calculateNewPosition
There was a problem hiding this comment.
Sure but it would be nicer to have one on the control itself that we can move things around. It's no big deal though
DominicOram
left a comment
There was a problem hiding this comment.
Thanks, I tidied up the mocks a bit more. Just the one comment now
|
|
||
| - id: daq-queue | ||
| path: /api/daq-queue/ | ||
| path: /api/blueapi/ |
There was a problem hiding this comment.
Must: Is this right? I think we want the queue on different endpoints to blueapi? If not then we will need to change the endpoints in the code?
There was a problem hiding this comment.
Discussed in person, this was just a typo, I will correct
DominicOram
left a comment
There was a problem hiding this comment.
Looks good to me. I think there's a few niggles but we should get this in now and iterate
Fixes #23 and https://jira.diamond.ac.uk/browse/I15_1-1625