docs: fixed some typos, formatting, grammar (#11540)

# Which Problems Are Solved - Typos - Punctuation - Markdown table formatting - ... (A bunch of issues my editor gave) # How the Problems Are Solved # Additional Changes # Additional Context
2026-11-08 07:05:12 +00:00 · 2026-02-13 07:45:17 +01:00
parent b0609aa861
commit 9b064d8b74
127 changed files with 764 additions and 760 deletions
@@ -16,7 +16,7 @@ If you on the other hand want users to be able to federate their accounts from a

 Further ZITADEL provided the possibility to disable registration on each IDP with the introduction of IDP Templates.

-To address this, we are going to change the behavior of the setting mentioned above, so that if disable, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.
+To address this, we are going to change the behavior of the setting mentioned above, so that if disabled, it will only prevent local registration. Registration of a federated user will still be possible - if not disabled by the corresponding IDP Template.

 ## Statement

@@ -14,7 +14,7 @@ Due to storage optimizations ZITADEL changes the behavior of sequences.
 This change improves command (create, update, delete) performance of ZITADEL.

 Sequences are no longer unique inside an instance.
-From now on sequences are upcounting per aggregate id.
+From now on sequences are counting up per aggregate id.
 For example sequences of newly created users begin at 1.
 Existing sequences remain untouched.

@@ -27,7 +27,7 @@ As soon as the release version is published, we will include the version here.

 If you use the ListEvents API to scrape events use the creation date instead of the sequence.
 If you use sequences on a list of objects it's no longer guaranteed to have unique sequences across the list.
-Therefore it's recommended to use the change data of the objects instead.
+Therefore, it's recommended to use the change data of the objects instead.

 ## Impact

@@ -12,7 +12,7 @@ Date: Calendar week 41/42 2023

 Versions >= 2.39.0 require the cockroach database user of ZITADEL to be granted to the `VIEWACTIVITY` grant. This can either be reached by grant the role manually or execute the `zitadel init` command.

-Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of Cockroachdb.
+Cockroach versions 22.2 < 22.2.11 and 23.1 < 23.1.4 will fail the migration. Please make sure to upgrade to more recent versions first. ZITADEL recommends to use the latest stable version of CockroachDB.

 ## Statement

@@ -22,7 +22,7 @@ To query correct order of events the cockroach database user of ZITADEL needs ad

 Before migrating to versions >= 2.39.0 make sure the cockroach database user has sufficient grants.

-Cockroachdb version is up to date.
+CockroachDB version is up to date.

 ## Impact

@@ -15,7 +15,7 @@ This advisory applies to self-hosted ZITADEL installations with custom roles to
 ## Description

 In upcoming ZITADEL versions, RBAC also applies to [system users defined in the ZITADEL runtime configuration](/guides/integrate/zitadel-apis/access-zitadel-system-api#runtime-configuration).
-This enables fine grained access control to the system API as well as other APIs for system users.
+This enables fine-grained access control to the system API as well as other APIs for system users.
 ZITADEL defines the new default roles *SYSTEM_OWNER* and *SYSTEM_OWNER_VIEWER*.
 System users without any memberships defined in the configuration will be assigned the *SYSTEM_OWNER* role.
 **Self-hosting users who define their own custom mapping at the *InternalAuthZ.RolePermissionMappings* configuration section**, have to define the *SYSTEM_OWNER* role in their configuration too to be able to access the system API with the default system user membership.
@@ -10,17 +10,17 @@ Date: 2024-05-28

 ## Description

-There were rare cases where Cockroachdb got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this github issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).
+There were rare cases where CockroachDB got blocked during runtime of ZITADEL and returned `WRITE_TOO_OLD`-errors to ZITADEL. The root cause of the problem is described in [this GitHub issue of the database](https://github.com/cockroachdb/cockroach/issues/77119). The workaround provided by the database is enabling the `enable_durable_locking_for_serializable`-flag as described [here](https://github.com/cockroachdb/cockroach/issues/75456#issuecomment-1936277716).

 Because enabling flags requires admin privileges the statement must be executed manually or by executing `zitadel init` command.

 ## Statement

-Ensure lock distribution for `FOR UPDATE`-statements on Cockroachdb.
+Ensure lock distribution for `FOR UPDATE`-statements on CockroachDB.

 ## Mitigation

-Cockroachdb version >= 23.2.
+CockroachDB version >= 23.2.

 ## Impact

@@ -17,13 +17,13 @@ they are reduced into projections in bulk batches. Projections allow for efficie

 We've investigated multiple reports of outdated projections.
 For example created users missing in get requests, or missing data after a ZITADEL upgrade[^1].
-The conclusion is that the transaction in which we perform a bulk of queries can timeout.
+The conclusion is that the transaction in which we perform a bulk of queries can time out.
 The old setting defined a transaction duration of 500ms for a bulk of 200 events.
 A single event may create multiple statements in a single projection.
 A timeout may occur even if the actual bulk size is less than 200,
-which then results in more back-pressure on a busy system, leading to more timeouts and effectively dead-locking a projection.
+which then results in more back-pressure on a busy system, leading to more timeouts and effectively deadlocking a projection.

-Increasing or disabling the projection transaction duration solved dead-locks in all reported cases.
+Increasing or disabling the projection transaction duration solved deadlocks in all reported cases.
 We've decided to increase the transaction duration to 1 minute.
 Due to the high value it is functionally similar to disabling,
 however it still provides a safety net for transaction that do freeze,
@@ -39,7 +39,7 @@ This change was submitted in the following PR:

 ## Mitigation

-If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection dead-lock consider increasing the timeout to the new default value.
+If you have a custom configuration for projections, this update will not apply to your system or some projections. When encountering projection deadlock consider increasing the timeout to the new default value.

 Note that entries under `Customizations` overwrite the global settings for a single projection.

@@ -21,7 +21,7 @@ Last updated: 2025-05-19

 ### Background

-Zitadel uses a eventstore table as main source of truth for state changes.
+Zitadel uses an eventstore table as main source of truth for state changes.
 Projections are tables which provide alternative views of state, which are built using events.
 In order to know which events are reduced into projections, we use a `position` column in the eventstore and a dedicated table which records the current state.

@@ -31,7 +31,7 @@ Zitadel prior to the listed version had a precision bug. The `position` column u

 ## Impact

-During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less then*, etc would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.
+During a past attempt to fix this, we got reports of failing projections inside Zitadel. Because the precision became exact certain compare operations like *equal*, *less than*, etc. would now return different results. This was because the values in `current_states` would already have lost precision from a broken version. This might happen to **some** deployments or projections: there is only a small probability.

 We are releasing the fix again and your system might get affected.