Files
zitadel/benchmark
fbe7b96138 fix(eventstore): prevent projections from skipping events (#12703)
<!-- CURSOR_AGENT_PR_BODY_BEGIN -->
# Which Problems Are Solved

Handler/v2 projections (`users14` and every other event projection) can
overlook committed events under load:

- `eventstore.commands_to_events` stamped `position` with `NOW()`
(transaction start). A slow create TX could commit after a faster TX
that started later, so the projector stored a later position and never
saw the earlier one.
- Resume used `OFFSET` on a **filtered** row count. That could skip
`in_tx_order = 1` at the next position (for example `user.human.added`).
- Two transactions in the same microsecond both start at `in_tx_order =
1`. A cursor of `in_tx_order > last` alone would drop the other TX’s
first event.

This does not repair rows that are already missing from projections.

# How the Problems Are Solved

- Setup step 77 replaces `eventstore.commands_to_events` so `created_at
= statement_timestamp()` and `position = EXTRACT(EPOCH FROM
clock_timestamp())` at INSERT time. Initialise `08_events_table.sql`
matches that for new databases. The function is `VOLATILE` to match
`clock_timestamp()`.
- The projector still drains in-flight writers with `pg_advisory_lock` /
`pg_advisory_unlock` in one statement, then caps with `position <=
EXTRACT(EPOCH FROM now())` (projector TX start). The exclusive lock is
**not** held across the event `SELECT`. The cap must stay `now()`, not
`clock_timestamp()`, or later inserts become a high-water mark.
- Resume is a lexicographic `EventSortKey` on `(position, in_tx_order,
instance_id, aggregate_type, aggregate_id, sequence)` via
`AfterEventSortKey`. SQL `OFFSET` is no longer used for projection
catch-up.
- Handler and FieldHandler persist the last event’s `in_tx_order` in
`current_states.filter_offset` (existing column, new meaning). Step 77
backfills matching rows from `events2`; unmatched rows keep their
previous value.

# Additional Changes

- `eventstore.Event` exposes `InTxOrder() uint32` (BaseEvent, repository
Event, v3 event, v1 models).
- v3 push SELECT/RETURNING now includes `in_tx_order` so newly written
events carry a real ordinal.
- `WithMinPosition` stays an inclusive `PositionAtLeast` floor and does
not smash the sort-key cursor.
- `SearchQuery.PositionAfter(decimal)` is unchanged (used by
access-token lookup). Do not confuse it with
`SearchQueryBuilder.AfterEventSortKey`.
- `commands_to_events` in setup 77 and initialise 08 is `VOLATILE
PARALLEL SAFE`. Shipped 40/64/70 stay `STABLE` because they still stamp
with `NOW()`.
- Drop unused `last_owner TEXT` DECLARE from setup 77 and initialise
`08_events_table.sql` (`i INTEGER` remains for the enforce-owner loop).
Shipped 40/64/70 keep the leftover.
- This PR’s migration is numbered 77 because `main` already has setup 76
(`76_users14_login_equality_indexes`). First-loop order is s70, then
main’s 76, then this 77.

# Additional Context

**Reviewer map**

| Start here | Why |
| --- | --- |
| `cmd/setup/77.sql` + `cmd/setup/77.go` | Position stamp + atomic
function replace/backfill after shipped `s70` and main’s s76 |
| `internal/eventstore/event_sort_key.go` + `search_query.go` |
Canonical cursor and `AfterEventSortKey` |
| `internal/eventstore/handler/v2/{state.go,handler.go}` |
Persist/resume cursor; `eventQuery` |
| `internal/eventstore/repository/sql/{query.go,postgres.go}` | Tuple
`>` filter, 6-column `ORDER BY`, await cap |
| `internal/eventstore/v3/push.go` / `push.sql` | Scan `in_tx_order` on
write |

Mechanical / low-risk: handler and query test fixtures, Event interface
stubs (`event_base.go`, repository Event, mocks, v1 models).

**Do not look for** a `70.sql` change — shipped migrations stay as on
`main`. Setup 40/64 still use `NOW()`; step 77 overwrites the function
afterward. Fresh `FirstInstance` (runs before `s70`) can still stamp
`NOW()` until 77; runtime pushes after 77 use `clock_timestamp()`.
Main’s `cmd/setup/76.go` is the users14 login-equality indexes, not this
stamp.

**Rollout**

1. Run setup so 77 replaces `commands_to_events` and backfills
`filter_offset`.
2. Restart ZITADEL so projectors load the new resume path.
3. Existing missing `users14` rows are not repaired by this PR.

**Tests**

- `go test ./internal/eventstore/... ./cmd/setup/`
- Sort-key SQL fixtures in `query_sort_key_test.go` (no `OFFSET`;
aggregate-id queries keep 6-column `ORDER BY`)
- `cmd/setup/77_test.go` asserts the embed has no unused `last_owner`
and still uses `clock_timestamp()` / `VOLATILE PARALLEL SAFE`

Related: #8509, #10480 (remove OFFSET), #10560 (advisory locks), #10710
(stable ORDER BY).
Out of scope: repairing already-missing projection rows, holding the
exclusive lock during SELECT, rewriting historical setup 40/64 SQL.
<!-- CURSOR_AGENT_PR_BODY_END -->

<div><a
href="https://cursor.com/agents/bc-3da6eb51-11d4-4a8a-8ba0-e190f116df05?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-web-light.png"><img
alt="Open in Web" width="114" height="28"
src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a>&nbsp;<a
href="https://cursor.com/background-agent?bcId=bc-3da6eb51-11d4-4a8a-8ba0-e190f116df05&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source
media="(prefers-color-scheme: dark)"
srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source
media="(prefers-color-scheme: light)"
srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img
alt="Open in Cursor" width="131" height="28"
src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a>&nbsp;</div>

---------

Co-authored-by: Cursor Agent <[email protected]>
Co-authored-by: Silvan <[email protected]>
2026-09-09 11:08:50 +02:00
..
2025-10-08 10:27:02 +02:00
2025-10-08 10:27:02 +02:00

Benchmarks

This package contains code for benchmarking specific endpoints of the API using k6.

Prerequisite

  • npm
  • k6
  • go
  • xk6 (make sure ~/go/bin is in your ${PATH})
  • running the API

Structure

The use cases under tests are defined in src/use_cases. The implementation of ZITADEL resources and calls are located under src.

Execution

Env vars

  • VUS: Amount of parallel processes execute the test (default is 20)
  • DURATION: Defines how long the tests are executed (default is 200s)
  • ZITADEL_HOST: URL of ZITADEL (default is http://localhost:8080)
  • ADMIN_LOGIN_NAME: Loginanme of a human user with IAM_OWNER-role
  • ADMIN_PASSWORD: password of the human user
  • USER_AMOUNT: Number of users created during setup for list-users benchmarks (default is 2500)
  • SETUP_CONCURRENCY: Max in-flight user-create requests during list-users setup (default is 50). Large USER_AMOUNT with unbounded parallelism can exhaust ephemeral ports (can't assign requested address).

To setup the tests we use the credentials of management console and log in using an admin. The user must be able to create organizations and all resources inside organizations.

Test

Before you run the tests you need an initialized user. The tests don't implement the change password screen during login.

  • make human_password_login
    setup: creates human users
    test: uses the previously created humans to sign in using the login ui
  • make machine_pat_login
    setup: creates machines and a pat for each machine
    test: calls user info endpoint with the given pats
  • make machine_client_credentials_login
    setup: creates machines and a client credential secret for each machine
    test: calls token endpoint with the client_credentials grant type.
  • make user_info
    setup: creates human users and signs them in
    test: calls user info endpoint using the given humans
  • make manipulate_user
    test: creates a human, updates its profile, locks the user and then deletes it
  • make introspect
    setup: creates projects, one api per project, one key per api and generates the jwt from the given keys
    test: calls introspection endpoint using the given JWTs
  • make add_session
    setup: creates human users
    test: creates new sessions with user id check
  • make oidc_session
    setup: creates a service account to create the auth request and session.
    test: creates an auth request, a session and links the session to the auth request. Implementation of this flow.
  • make otp_session
    setup: creates 1 human user for each VU and adds OTP Email to it
    test: creates a session based on the login name of the user, sets the OTP Email challenge to the session and afterwards checks the OTP code
  • make password_session
    setup: creates 1 human user for each VU and adds OTP Email to it
    test: creates a session based on the login name of the user and checks for the password on a second step
  • make machine_jwt_profile_grant
    setup: generates private/public key, creates service accounts, adds a key
    test: creates a token and calls user info
  • make machine_jwt_profile_grant_single_user
    setup: generates private/public key, creates service account, adds a key
    test: creates a token and calls user info in parallel for the same user
  • make users_by_metadata_key
    setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user test: calls the list users endpoint and filters by a metadata key
  • make users_by_metadata_value
    setup: creates for half of the VUS a human user and a machine for the other half, adds 3 metadata to each user test: calls the list users endpoint and filters by a metadata value
  • make users_by_login_name
    setup: creates USER_AMOUNT human users (default 2500) in a new org, with SETUP_CONCURRENCY parallel creates (default 50)
    test: calls ListUsers the same way as login v2 (loginNameQuery with EQUALS_IGNORE_CASE, organizationIdQuery, limit: 2)
    note: to reproduce multi-second latency on the old query plan, use a large dataset, e.g. USER_AMOUNT=100000 VUS=10 DURATION=60s
  • make verify_all_user_grants_exists
    setup: creates 50 projects, 1 machine per VU test: creates a machine and grants all projects to the machine teardown: the organization is not removed to verify the data of the projections are correct. You can find additional information at the bottom of this file