Fix assorted typos (#609)

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.

docs/explanations/events.md

@@ -9,22 +9,22 @@ 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.
 
 ## 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.
 

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.

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.
 

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
 
 

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")

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")