diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 67558b62ed..fb1759fc0e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -26,7 +26,7 @@ The **ElectricSQL repositories** are defined as any repository hosted on the Git ## Contributor Guidelines -Please read the guideance below about what to do if you: +Please read the guidance below about what to do if you: - [found a bug](#did-you-find-a-bug) - [fixed a bug](#did-you-write-a-patch-that-fixes-a-bug) diff --git a/docs/about.md b/docs/about.md index cb61ef8bb2..d2ef49011e 100644 --- a/docs/about.md +++ b/docs/about.md @@ -213,7 +213,7 @@ So, following the strategy of paring down to the core and then progressively lay This explicitly reduces the capability of the system in the short term, in order to build a better, more resilient system in the long term. The beauty is that, because we no longer prescribe a write-path strategy, you can choose and if necessary implement any write-path strategy you like. -We will only focus on the more complex strategies ourseves once the simpler ones are bulletproof. And we hope that others, like [LiveStore](https://www.schickling.dev/projects/livestore) and [Drizzle](https://orm.drizzle.team/), for example, will build better client-side libraries that we can. +We will only focus on the more complex strategies ourselves once the simpler ones are bulletproof. And we hope that others, like [LiveStore](https://www.schickling.dev/projects/livestore) and [Drizzle](https://orm.drizzle.team/), for example, will build better client-side libraries that we can. #### A note on finality of local writes diff --git a/docs/api/http.md b/docs/api/http.md index b06b91911d..96151a6142 100644 --- a/docs/api/http.md +++ b/docs/api/http.md @@ -59,7 +59,7 @@ When you make an initial sync request, with `offset=-1`, you're telling the serv When a shape is first requested, Electric queries Postgres for the data and populates the log by turning the query results into insert operations. This allows you to sync shapes without having to pre-define them. Electric then streams out the log data in the response. -Sometimes a log can fit in a single response. Sometimes it's too big and requires multiple requests. In this case, the first request will return a batch of data and an `x-electric-chunk-last-offset` header. An HTTP client should then continue to make requests setting the `offset` parameter to the this header value. This allows the client to paginate through the shape log until it has recieved all the current data. +Sometimes a log can fit in a single response. Sometimes it's too big and requires multiple requests. In this case, the first request will return a batch of data and an `x-electric-chunk-last-offset` header. An HTTP client should then continue to make requests setting the `offset` parameter to the this header value. This allows the client to paginate through the shape log until it has received all the current data. ### Control messages diff --git a/docs/guides/telemetry.md b/docs/guides/telemetry.md index b0fdc35ee8..b80017636e 100644 --- a/docs/guides/telemetry.md +++ b/docs/guides/telemetry.md @@ -26,7 +26,7 @@ Electric always adds the following resource attributes to events: %{service: %{name: service_name, version: version}, instance: %{id: instance_id}} ``` -Attributes `service_name` and `instance_id` can be overriden with `ELECTRIC_SERVICE_NAME` and `ELECTRIC_INSTANCE_ID` respectively. By default, `instance_id` is an uuid. +Attributes `service_name` and `instance_id` can be overridden with `ELECTRIC_SERVICE_NAME` and `ELECTRIC_INSTANCE_ID` respectively. By default, `instance_id` is an uuid. Electric will also load additional resource attributes from `OTEL_RESOURCE_ATTRIBUTES`. Learn more about resource attributes in [OpenTelemetry documentation](https://opentelemetry.io/docs/languages/js/resources/).