Andrei Zimin
83caf9c3c8
Implements the Phase 2 hook from the previous commit. With this in
place, UserDisplayService.find chains:
hot cache → DB (user_display_cache) → Keycloak Admin API
so any realm user resolves on first display, even if they never made
an authenticated request to ordinis. The resolved entry is persisted
via UserDisplayService.upsert with source=KEYCLOAK_ON_DEMAND, so the
next render of the same sub hits the DB tier (~ms) instead of going
back to Keycloak.
Implementation notes:
- Spring RestClient (modern blocking HTTP, replaces RestTemplate).
- client_credentials grant against
{issuer}/realms/{realm}/protocol/openid-connect/token. Token cached
in-memory minus a 30s safety margin from `expires_in`.
- 401 on user lookup wipes the cached token and surfaces a
RuntimeException, so the next resolve refetches.
- 404 on user lookup → Optional.empty (definitive miss, sub not in
realm). UserDisplayService logs and the caller falls back to short
UUID. Negative cache TTL not implemented — added complexity not
justified for the current realm size (~50 users).
- Bean activated only when ordinis.keycloak.admin.enabled=true AND
the env vars are set. Default disabled — UserDisplayService treats
KeycloakUserResolver as @Autowired(required = false), so a
deployment without Keycloak admin creds keeps the previous behavior
(DB cache only) instead of crashing on startup.
Application config:
- ORDINIS_KEYCLOAK_ADMIN_ENABLED (false by default)
- ORDINIS_KEYCLOAK_ADMIN_URL e.g. https://auth.nstart.space
- ORDINIS_KEYCLOAK_ADMIN_REALM defaults to nstart
- ORDINIS_KEYCLOAK_ADMIN_CLIENT_ID via vault (see docs-internal/keycloak-admin-setup.md)
- ORDINIS_KEYCLOAK_ADMIN_CLIENT_SECRET via vault
Setup runbook (docs-internal/keycloak-admin-setup.md) covers:
- creating the Keycloak service-account client + assigning view-users
- writing the secret into both vault instances (different per env)
- wiring vault.hashicorp.com agent-inject annotations into the chart
- verification steps + common failure modes
Phase 3 (scheduled bulk sync) is documented at the end of the runbook
but deferred — depends on observed cache miss rate after this lands.
Ordinis — internal documentation
Технические детали реализации, архитектура, operator runbooks и project state snapshots. НЕ deployment'ится через Diplodoc — это внутренние артефакты для команды Ordinis (не для consumers).
Consumer-facing документация находится в docs/ и build'ится через
Diplodoc → static HTML.
Что внутри
docs-internal/
├── ops/ # Operator runbook (on-call, incidents, recovery)
│ ├── README.md
│ ├── slo.md
│ ├── outbox-dlq.md
│ ├── db-migrations.md
│ ├── vault-unseal.md
│ └── kafka-restart.md
├── status/ # Project state snapshots (по дням сессий)
│ └── *-state.md
└── tech/ # Архитектурные deep-dives, legacy документы
└── api-integration.md # legacy (мигрирован в docs/integration/api/)
Когда что использовать
| Situation | Read |
|---|---|
| Я — consumer интегрирующий свой backend | docs/integration/api/ (Diplodoc) |
| Я — on-call инженер с alert | ops/README.md |
| Я — Ordinis dev планирующий feature | status/ latest snapshot + design docs в ~/.gstack/projects/claude/ |
| Я — новый разработчик в команде | Сначала consumer docs, потом ops/, потом status/ для context |
Архитектурные artifacts (вне репозитория)
Design docs / план-плансы хранятся в ~/.gstack/projects/claude/:
zimin-main-design-production-prep-20260507-123032.md— prod stand-up planzimin-main-design-approval-workflow-v2-20260507-121632.md— approval flow v2 (DEFERRED)zimin-main-design-dict-relationships-v2-20260507-230237.md— lineage + cascade rulescheckpoints/*.md— session state checkpoints для context-restore
Rationale разделения
Diplodoc документация — public contract для интеграторов:
- Может быть опубликована на public Pages
- Не должна leak'ать internal architecture (security)
- Должна быть стабильной (consumer'ы строят на ней свои интеграции)
docs-internal/ — operational state:
- Runbooks меняются часто (incidents, lessons learned)
- Status snapshots — historical record для команды
- Tech deep-dives — для разработчиков, не consumers
Это разделение делает Diplodoc более фокусированным и менее шумным для consumers.