diff --git a/docs/explanations/architecture.md b/docs/explanations/architecture.md index c829ebc73..f3c8cf848 100644 --- a/docs/explanations/architecture.md +++ b/docs/explanations/architecture.md @@ -30,5 +30,5 @@ the known expectations of the plan, passes it to the `RunEngine` and handles any ### The Service Object Handles communications and the API layer. This object holds a reference to the worker -can interrogate it/give it instructions in response to messages it recieves from the message +can interrogate it/give it instructions in response to messages it receives from the message bus. It can also forward the various events generated by the worker to topics on the bus. diff --git a/docs/explanations/events.md b/docs/explanations/events.md index 990d0b36b..dbd4ac98d 100644 --- a/docs/explanations/events.md +++ b/docs/explanations/events.md @@ -9,14 +9,14 @@ Since the `RunEngine` is traditionally used by a human in front of an IPython te sometimes assumes intuitive behaviour. The worker replaces the human and so must fill in the gaps. -The base engine programatically emits data events conforming to the `bluesky event model`_. These +The base engine programmatically emits data events conforming to the `bluesky event model`_. These are meant to be handled by other subscribing code (e.g. databroker) and are decoupled from concerns such as whether a plan has started, finished, paused, errored etc. See the example below: ![sequence of event emission compared to plan start/finish, in a complicated case](../images/bluesky-events.png) Note the gap between the start of the plan and the issue of the first [`run start document`](https://blueskyproject.io/event-model/main/user/explanations/data-model.html#run-start-document), and the similar gap -for the stop document vs end of the plan, thsse are typically used for setup and cleanup. +for the stop document vs end of the plan, thsse are typically used for setup and cleanup. Also note that a plan can produce an arbitrary number of runs. This decoupling is fine in an IPython terminal because a human user can see when a plan has started, can see when it's finished and can see which runs are associated with which plans. @@ -24,7 +24,7 @@ associated with which plans. ## New Events For the case of automation, we introduce a new set of events outside of the event model, specifically -pertaining to the running of the plan and state of the `RunEngine`. At a mimimum, an event is emitted +pertaining to the running of the plan and state of the `RunEngine`. At a minimum, an event is emitted every time the engine: * Starts a new plan @@ -37,7 +37,7 @@ In the latter case, information about the error is also included. ## Correlation ID -When controlling plans programatically, it can be useful to verify that event model documents really are related to +When controlling plans programmatically, it can be useful to verify that event model documents really are related to the plan you just asked the worker to run. The worker will therefore bundle a correlation ID into the headers of messages containing documents. diff --git a/docs/explanations/lifecycle.md b/docs/explanations/lifecycle.md index 286350c93..862f3a754 100644 --- a/docs/explanations/lifecycle.md +++ b/docs/explanations/lifecycle.md @@ -23,7 +23,7 @@ of being written, loaded and run. Take the following plan. Args: detectors (List[Readable]): Readable devices to read: when being run in Blueapi defaults to fetching a device named "det" from its - context, else will require to be overriden. + context, else will require to be overridden. num (int, optional): Number of readings to take. Defaults to 1. delay (Optional[Union[float, List[float]]], optional): Delay between readings. Defaults to None. diff --git a/docs/reference/messaging-spec.md b/docs/reference/messaging-spec.md index 40bb8544b..363577c80 100644 --- a/docs/reference/messaging-spec.md +++ b/docs/reference/messaging-spec.md @@ -3,5 +3,5 @@ The Blueapi service publishes Bluesky documents and other events to the message bus, allowing subscribers to keep track of the status of plans, as well as other status changes. This page documents the channels to which clients can -subscribe to recieve these messages and their structure. +subscribe to receive these messages and their structure. diff --git a/tests/core/test_context.py b/tests/core/test_context.py index b3b8a32ee..2557415bf 100644 --- a/tests/core/test_context.py +++ b/tests/core/test_context.py @@ -231,11 +231,11 @@ def test_lookup_device(devicey_context: BlueskyContext, addr: str | list[str]) - assert is_bluesky_compatible_device(device) -def test_lookup_nonexistant_device(devicey_context: BlueskyContext) -> None: +def test_lookup_nonexistent_device(devicey_context: BlueskyContext) -> None: assert devicey_context.find_device("foo") is None -def test_lookup_nonexistant_device_child(devicey_context: BlueskyContext) -> None: +def test_lookup_nonexistent_device_child(devicey_context: BlueskyContext) -> None: assert devicey_context.find_device("sim.foo") is None diff --git a/tests/service/test_rest_api.py b/tests/service/test_rest_api.py index 7cf925932..86b22b9c7 100644 --- a/tests/service/test_rest_api.py +++ b/tests/service/test_rest_api.py @@ -80,7 +80,7 @@ class MyModel(BaseModel): @patch("blueapi.service.interface.get_plan") -def test_get_non_existant_plan_by_name( +def test_get_non_existent_plan_by_name( get_plan_mock: MagicMock, client: TestClient ) -> None: get_plan_mock.side_effect = KeyError("my-plan") diff --git a/tests/worker/test_task_worker.py b/tests/worker/test_task_worker.py index 97c050c46..96777db9b 100644 --- a/tests/worker/test_task_worker.py +++ b/tests/worker/test_task_worker.py @@ -161,7 +161,7 @@ def test_clear_task(worker: TaskWorker) -> None: assert worker.get_tasks() == [] -def test_clear_nonexistant_task(worker: TaskWorker) -> None: +def test_clear_nonexistent_task(worker: TaskWorker) -> None: with pytest.raises(KeyError): worker.clear_task("foo")