i15-1: display basic feedback from blueapi

[noemifrisina]

See https://jira.diamond.ac.uk/browse/I15_1-1539

[DominicOram]

Thanks, some comments in code, additionally:

• I can quite easily trigger multiple plans at once by just hitting the button twice. This is probably because of the fact we have to do two calls to BlueAPI to run the plan and we only disable the button on the second call. This should be fixed when BlueAPI moves away from the two calls in DiamondLightSource/blueapi#1326 but can we have an issue that acknowledges this?
• We should move Abort and WorkerState into blueapi-query as they seem common. Also update the docs in there so that people know it's available

[DominicOram]

Should: Can we have some tests on the logic in this?

[DominicOram]

Could: Can we pull these into constants somewhere?

[DominicOram]

Should: Can we have a test on this

[DominicOram]

Thanks, some more comments in code, I think there may have been a bad merge? Also, I still stand by wanting unit tests on some of the logic...

[DominicOram]

Must: I think this is a duplicate of the existing card. Maybe a bad merge?

[DominicOram]

Must: This is no longer used? I think we want it here, right?

[noemifrisina]

Added a few tests but after looking at some documentation, it seems that in order to be able to test the logic I would need to get those functions out of the component (can't test functions nested inside). Tbh, I would rather do that in a separate PR and get this functionality merged...

[EmsArnold]

One comment in code, and then a further general comment:
If we're moving forward with the logic as is, and re-factoring the logic outside the component in the (near) future, it would be good to create an issue detailing the necessary work now and leave the new issue linked in a relevant location.

[EmsArnold]

Seems like the first time a task fails, the snackbar shows the correct message:

Failed to run plan robot_load, see console and blueapi logs for full error.

However, the console message shows the default message:

Running robot_load plan.
 Reason: AxiosError: Request failed with status code 404

I imagine this is something that may also be fixed by refactoring the logic outside the component?

[noemifrisina]

Good spot, I hadn't noticed it. Tbh, not so sure just refactoring the logic out will fix this - not on its own at least. At least the error is the correct one (the latest), but it's still taking the old message. I have seen it in the past where the new message doesn't show up right away after the set in the same function, but can't remember what the fix was so will have to go look

[noemifrisina]

Ok, after a quick read, I remember now. Long story short, not only is useState asynchronous, but the current state of msg actually would not change till next re-render. In general there's a few solutions to this if needed, but in this case since we just want the error messages to match I would simply update the log to not use msg directly...

[EmsArnold]

Coverage seems to be failing with an error:
TestingLibraryElementError: Unable to find an element by: [data-testid="Plan succeeded"]

  ❯ src/RunPlanButton.test.tsx:104:19
    102|     screen.getByText("Run").click();
    103|     expect(screen.findByTestId("Plan submission successful!"));
    104|     expect(screen.findByTestId("Plan succeeded"));
       |                   ^
    105|   });
    106| 

This likely originated from a mistake in my original RunPlanButton, but curious that CI is passing... Should these screen.findByTestId be screen.findByText?

[noemifrisina]

I actually changed them to findByTestId because findByText was failing... Checking a couple of things, I'm starting to think this test is flaky (it was passing then not, then passing again, with no changes)

[EmsArnold]

Looks good to me, but we should keep an eye on the suspected flaky test in the future.

Comments addressed