# Which Problems Are Solved
We saw high CPU usage if many events were created on the database. This
was caused by the new actions which query for all event types and
aggregate types.
# How the Problems Are Solved
- the handler of action execution does not filter for aggregate and
event types.
- the index for `instance_id` and `position` is reenabled.
# Additional Changes
none
# Additional Context
none
# Which Problems Are Solved
In rare cases there was a possibility that multiple users were found by
a loginname. This prevented the corresponding user to sign in.
# How the Problems Are Solved
Fixed the corresponding query (to correctly respect the org domain
policy).
# Additional Changes
None
# Additional Context
Found during the investigation of a support request
# Which Problems Are Solved
Currently, users can't delete themselves using the V2 RemoveUser API
because of the redunant API middleware permission check.
On main, using a machine user PAT to delete the same machine user:
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
ERROR:
Code: NotFound
Message: membership not found (AUTHZ-cdgFk)
Details:
1) {
"@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
"id": "AUTHZ-cdgFk",
"message": "membership not found"
}
```
Same on this PRs branch:
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
{
"details": {
"sequence": "3",
"changeDate": "2025-05-06T13:44:54.349048Z",
"resourceOwner": "318838541083804033"
}
}
```
Repeated call
```bash
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"userId": "318838604669387137"}' localhost:8080 zitadel.user.v2.UserService.DeleteUser
ERROR:
Code: Unauthenticated
Message: Errors.Token.Invalid (AUTH-7fs1e)
Details:
1) {
"@type": "type.googleapis.com/zitadel.v1.ErrorDetail",
"id": "AUTH-7fs1e",
"message": "Errors.Token.Invalid"
}
```
# How the Problems Are Solved
The middleware permission check is disabled and the
domain.PermissionCheck is used exclusively.
# Additional Changes
A new type command.PermissionCheck allows to optionally accept a
permission check for commands, so APIs with middleware permission checks
can omit redundant permission checks by passing nil while APIs without
middleware permission checks can pass one to the command.
# Additional Context
This is a subtask of #9763
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
When a user changes their password, Zitadel needs to terminate all of
that user's active sessions. This query can take many seconds on
deployments with large session and user tables. This happens as part of
session projection handling, so doesn't directly impact user experience,
but potentially bogs down the projection handler which isn't great. In
the future, this index could be used to power a "see all of my current
sessions" feature in Zitadel.
# How the Problems Are Solved
Adds new index on `user_id` column on `projections.sessions8` table.
Alternatively, we can index on `(instance_id, user_id)` instead but
opted for keeping the index smaller as we already index on `instance_id`
separately.
# Additional Changes
None
# Additional Context
None
---------
Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com>
# Which Problems Are Solved
The sorting column of action targets and executions defaults to the ID
column instead of the creation date column.
This is only relevant, if the sorting column is explicitly passed as
unspecified.
If the sorting column is not passed, it correctly defaults to the
creation date.
```bash
# ❌ Sorts by ID
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"sortingColumn": "TARGET_FIELD_NAME_UNSPECIFIED"}' localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
# ❌ Sorts by ID
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" -d '{"sortingColumn": 0}' localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
# ✅ Sorts by creation date
grpcurl -plaintext -H "Authorization: Bearer ${ZITADEL_ACCESS_TOKEN}" localhost:8080 zitadel.action.v2beta.ActionService.ListTargets
```
# How the Problems Are Solved
`action.TargetFieldName_TARGET_FIELD_NAME_UNSPECIFIED` maps to the
sorting column `query.TargetColumnCreationDate`.
# Additional Context
As IDs are also generated in ascending, like creation dates, the the bug
probably only causes unexpected behavior for cases, where the ID is
specified during target or execution creation. This is currently not
supported, so this bug probably has no impact at all. It doesn't need to
be backported.
Found during implementation of #9763
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
In Actions v2, if a target is removed, which is still used in an
execution, the target is still listed when list executions.
# How the Problems Are Solved
Removed targets are now also removed from the executions.
# Additional Changes
To be sure the list executions include a check if the target is still
existing.
# Additional Context
None
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Users from Google IDP's are not unmarshalled correctly in intent
endpoints and not returned to callers.
# How the Problems Are Solved
Provided correct type for unmarshalling of the information.
# Additional Changes
None
# Additional Context
None
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
# Which Problems Are Solved
Instance that had improved performance flags set, got event errors when
getting instance features. This is because the improved performance
flags were marshalled using the enumerated integers, but now needed to
be unmashalled using the added UnmarshallText method.
# How the Problems Are Solved
- Remove emnumer generation
# Additional Changes
- none
# Additional Context
- reported on QA
- Backport to next-rc / v3
# Which Problems Are Solved
The `auth.auth_requests` table is not cleaned up so long running Zitadel
installations can contain many rows.
The mirror command can take long because a the data are first copied
into memory (or disk) on cockroach and users do not get any output from
mirror. This is unfortunate because people don't know if Zitadel got
stuck.
# How the Problems Are Solved
Enhance logging throughout the projection processes and introduce a
configuration option for the maximum age of authentication requests.
# Additional Changes
None
# Additional Context
closes https://github.com/zitadel/zitadel/issues/9764
---------
Co-authored-by: Livio Spring <livio.a@gmail.com>
