diff --git a/.codespell-ignore-words b/.codespell-ignore-words
new file mode 100644
index 0000000000000000000000000000000000000000..9b52f093b3a44f508c3b04f887fb252c4e9ee6af
--- /dev/null
+++ b/.codespell-ignore-words
@@ -0,0 +1 @@
+connexion
diff --git a/README.md b/README.md
index 2dc039e1a21cf9a207fa6010586eeeb0d328d067..cc0d7bc85f65619f5ccbba4ce35ea63da23e2809 100644
--- a/README.md
+++ b/README.md
@@ -67,7 +67,7 @@ acting as a reverse proxy.
### Redundant Deployment
In this scenario there are two Engine instances involved. Here you will need to deploy one Engine API on the host of each Engine instance. Additionally you'll have to set up
-a third, so-called *Syncronization Node* of the Engine API. This sync instance of Engine API is in charge of synchronizing playlogs and managing the active engine state.
+a third, so-called *Synchronization Node* of the Engine API. This sync instance of Engine API is in charge of synchronizing playlogs and managing the active engine state.
<img src="docs/engine-api_redundancy.png" />
@@ -89,8 +89,8 @@ acting as a reverse proxy to shield your API.
Usually when some new audio source starts playing, AURA Engine logs it to its local Engine API instance via some REST call. Now, the *Local API server* stores this information in its
local database. Next, it also performs a POST request to the *Synchronization API Server*. This *Sync Node* checks if this request is coming from the currently active engine instance.
-If yes, it stores this information in its playlog database. This keeps the playlogs of individual (currently active) Engine instances in sync with the *Engine API syncronization node*.
-The *Engine API syncronization node* always only stores the valid (i.e. actually played) playlog records.
+If yes, it stores this information in its playlog database. This keeps the playlogs of individual (currently active) Engine instances in sync with the *Engine API synchronization node*.
+The *Engine API synchronization node* always only stores the valid (i.e. actually played) playlog records.
##### Active Sync
@@ -103,7 +103,7 @@ obviously can not be synced. That means the local playlog at the *Engine Node* i
Such marked entries are focus of the secondary synchronization approach, the so called **Passive Sync**: Whenever the *Synchronization Node* is up- and running again, some automated job
on this node is continuously checking for records on remote nodes marked as "unsynced". If there are such records found, this indicates that there has been an outage of the *Sync Node*.
Hence those "unsynced" records are pending to be synced. Now an automated job on the *Sync Node* reads those records as batches from that Engine Node and stores them in its local database.
-It also keeps track when the last sync has happend, avoiding to query unnecceary records on any remote nodes.
+It also keeps track when the last sync has happened, avoiding to query unnecceary records on any remote nodes.
In order to avoid that this **Passive Sync** job might be causing high traffic on an engine instance, these batches are read with some configured delay time (see `sync_interval` and
`sync_step_sleep` in the *Sync Node* configuration; all values are in seconds) and a configurable batch size (`sync_batch_size`; count of max unsynced playlogs which are read at once).
@@ -243,7 +243,7 @@ To run the API in an local development server execute:
./run.sh dev
```
-This command implicitely activates the virtual environment before starting the API.
+This command implicitly activates the virtual environment before starting the API.
For convenience running a plain `./run.sh` also starts the development server.
diff --git a/src/rest/util.py b/src/rest/util.py
index ae481251bd02adeacc7374943b0897831cf87cd9..05878d324fecd1c1e8ecad65eaa9c466bfa78b0a 100644
--- a/src/rest/util.py
+++ b/src/rest/util.py
@@ -24,7 +24,7 @@ def _deserialize(data, klass):
elif klass == datetime.datetime:
return deserialize_datetime(data)
- # NOTE: Due to Pyton 3.7 not providing `typing.GenericMeta` anymore,
+ # NOTE: Due to Python 3.7 not providing `typing.GenericMeta` anymore,
# this workaround is needed (See https://github.com/swagger-api/swagger-codegen/issues/8921)
# As soon this has been fixed in SwaggerHub Codegen this class can
# be replaced by the generated one again.
diff --git a/src/service.py b/src/service.py
index 7d5c4e5054f3cf066c9c88cce28bfbbb6c6610c2..04df1d364e9650f5bde75ceaea2328748b30afbd 100644
--- a/src/service.py
+++ b/src/service.py
@@ -167,7 +167,7 @@ class ApiService:
if not data.log_source:
data.log_source = self.config.get("host_id")
- # Main Node: Alway log entry, independed of the source
+ # Main Node: Always log entry, independent of the source
# Sync Node: Only log entry when it's coming from an active source
if self.node_type == NodeType.MAIN or (
self.node_type == NodeType.SYNC and data.log_source == self.active_source
@@ -347,7 +347,7 @@ class ApiService:
if not source_number:
source_number = self.host_id
- # Main Node: Alway log entry, independed of the source
+ # Main Node: Always log entry, independent of the source
# Sync Node: Only log entry when it's coming from an active source
if self.node_type == NodeType.MAIN or (
self.node_type == NodeType.SYNC and source_number == self.active_source
diff --git a/src/sync.py b/src/sync.py
index a06fa49ac1716f71f036ec6945a11a2f7e6bc5ce..7dd7f4ab9072a55a647bf29c6e9e17d31fffc566 100644
--- a/src/sync.py
+++ b/src/sync.py
@@ -172,7 +172,7 @@ class SyncJob(threading.Thread):
"""
Create and store the next source in the ActivityLog. It's actually the same,
as the current, but acts as a references for the current sync and as a marker
- for the entrypoint of the next sync -> to avoid unneccessary sync cycles.
+ for the entrypoint of the next sync -> to avoid unnecessary sync cycles.
"""
next_source = ActivityLog(current_source.source_number)
self.Session.add(next_source)