Зберігання та експорт даних

Railhook зберігає кожну подію, спробу й вхідну подію; лише строк зберігання не дає цим таблицям рости безкінечно.

Що зберігається і скільки

Ці значення задають у .env:

Дані	Змінна	Типово
Невдалі спроби	`DATA_RETENTION_ATTEMPTS_DAYS`	90 днів
Успішні (2xx) спроби	`DATA_RETENTION_SUCCESSFUL_ATTEMPTS_DAYS`	14 днів
Події	`DATA_RETENTION_EVENTS_DAYS`	90 днів
Вхідні події	`DATA_RETENTION_INCOMING_EVENTS_DAYS`	30 днів
Скільки спроб зберігати для однієї доставки	`DATA_RETENTION_MAX_ATTEMPTS_PER_DELIVERY`	10
Журнал запитів тунелю	—	7 днів

Чому саме такі:

Успішні спроби видаляються першими. Спроба з 2xx мало що каже, коли відомо, що вона спрацювала; невдала є матеріалом для налагодження. Видалення успішних через 14 днів прибирає більшу частину обсягу й лишає все потрібне для розбору.
Події та невдалі спроби зберігаються однаково, 90 днів. Якщо тримати спроби довше за їхню подію, лишаться записи, що посилаються в нікуди.
Ліміт спроб на доставку ловить те, чого не зловить строк: ендпоінт, що тиждень відповідає помилками, додає спроби до однієї доставки.

Коли запускається очищення

Завдання	Типовий розклад	Змінна
Основне очищення	Щодня о 02:00	`DATA_RETENTION_CRON`
Ліміт спроб на доставку	Кожні 30 хв	`DATA_RETENTION_LIMIT_CRON`
Очищення після сплесків	Кожні 4 год	`DATA_RETENTION_BURST_CLEANUP_CRON`
Метрики розміру таблиць	Кожні 15 хв	`DATA_RETENTION_TABLE_METRICS_INTERVAL_MS`

Записи видаляються пакетами по DATA_RETENTION_BATCH_SIZE (типово 1000), тож перший запуск після тривалої перерви не блокує платформу.

Спроби доставки й журнал запитів тунелю в Postgres розбито на партиції за часом, тож прострочений період видаляється цілою партицією, миттєво, а не записами по одному. PARTITION_MAINTENANCE_ENABLED (типово true) створює партиції наперед і видаляє прострочені.

Перевірте, що очищення працює

Метрика	Що означає
`delivery_attempts_table_rows`, `events_table_rows`, `incoming_events_table_rows`	Приблизна кількість записів у кожній великій таблиці
`delivery_attempts_cleanup_total`, `events_cleanup_total`, `incoming_events_cleanup_total`	Скільки записів видалено
`partition_dropped_total`	Скільки партицій видалено
`partition_default_rows`	Записи, що потрапили в типову партицію. Має бути нуль; будь-яке інше значення означає, що потрібної партиції не було.

Таблиця росте, а лічильник очищення стоїть: завдання не запускається. Перевірте значення cron і логи API близько 02:00.

Експорт організації

Власник експортує організацію через GET /api/v1/orgs/{orgId}/export: один JSON-документ з організацією, учасниками, проєктами, ендпоінтами, підписками, джерелами, призначеннями, API-ключами та записами аудиту.

Вмісту подій там немає. Події, доставки й спроби надто великі для одного документа. Попередьте кожного, хто відповідатиме цим файлом на запит суб’єкта даних про доступ.
Записів аудиту не більше 10 000. Якщо ліміт спрацював, auditLogsTruncated дорівнює true, а auditLogsTotal містить справжню кількість.

Видалення даних

Уся організація. Власник видаляє її через DELETE /api/v1/orgs/{orgId} разом з усім, що їй належить. Журнал аудиту навмисно зберігається як доказ видалення.

Обліковий запис однієї людини. Людина видаляє його сама через DELETE /api/v1/auth/me:

Персональні дані замінюються, і в цей обліковий запис більше ніколи не можна буде увійти. Усі сесії закриваються, а людину виключають з усіх організацій.
Організація, де людина була єдиним учасником, видаляється разом з обліковим записом.
Запит повертає 409, якщо людина є останнім власником організації з іншими учасниками. Спершу передайте права власника.

І видалення, і експорт записуються в журнал аудиту.