From b39f91251201353b62ddf6e0bbf03d434bdca3ae Mon Sep 17 00:00:00 2001 From: Maria Grimaldi Date: Mon, 17 Feb 2025 09:14:09 +0100 Subject: [PATCH] docs: apply suggestions from code review Co-authored-by: Sarina Canelake --- docs/how-tos/add-new-event-bus-concrete-implementation.rst | 2 +- docs/how-tos/create-a-new-event.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/how-tos/add-new-event-bus-concrete-implementation.rst b/docs/how-tos/add-new-event-bus-concrete-implementation.rst index ec2400f1e..e6502b4b9 100644 --- a/docs/how-tos/add-new-event-bus-concrete-implementation.rst +++ b/docs/how-tos/add-new-event-bus-concrete-implementation.rst @@ -25,7 +25,7 @@ At a high level, the consumer should be a process that takes the signals and eve The consumer class then needs to implement ``consume_indefinitely`` loop, which will stay running and listen to events as they come in. -We have included an utility function called `prepare_for_new_work_cycle `_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture. +We have included a utility function called `prepare_for_new_work_cycle `_ in openedx-events which needs to be called before processing any signal. Currently, it reconnects the db connection if required as well as clears RequestCache and there may be later, more comprehensive changes. These steps mimic some setup/teardown that is normally performed by Django in its request/response based architecture. Check out `consumer.py `_ in the event bus redis implementation. diff --git a/docs/how-tos/create-a-new-event.rst b/docs/how-tos/create-a-new-event.rst index ae541964f..e3c889a32 100644 --- a/docs/how-tos/create-a-new-event.rst +++ b/docs/how-tos/create-a-new-event.rst @@ -186,7 +186,7 @@ The :term:`Event Definition` should be implemented in the corresponding subdomai } ) -- The event definition should be documented using in-line documentation with at lest ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information. +- The event definition should be documented using in-line documentation with at least ``event_type``, ``event_name``, ``event_key_field``, ``event_description``, ``event_data`` and ``event_trigger_repository``. This will help consumers understand the event and react to it. See :doc:`../reference/in-line-code-annotations-for-an-event` for more information. - The :term:`Event Type` should be unique and follow the naming convention for event types specified in the :doc:`../decisions/0002-events-naming-and-versioning` ADR. This is used by consumers to identify the event. - The ``event_name`` should be a constant that is used to identify the event in the code. - The ``event_key_field`` should be a field in the payload that uniquely identifies the event. This is used by consumers to identify the event.