GHOST-01: soft delete — это не delete

Как удалённый пользователь получил appointment. И что это говорит о том, что значит «удалить» сущность в системе с soft delete.

Пользователь удалён. Appointment создан.

Для удалённого пользователя.

Контекст

Система клиники: пациенты бронируют слоты к врачам. Если слот занят — попадают в вейтлист. Когда appointment отменяется — первый из вейтлиста автоматически получает слот.

Удаление пользователей реализовано через soft delete: в таблице users есть поле deletedAt. «Удалённый» пользователь — это обычная запись с заполненным deletedAt. Физически запись никуда не исчезает.

Это стандартная практика: soft delete позволяет сохранить историю, восстановить данные, не нарушать foreign key constraints.

Инцидент

Fixture teardown в тесте:

1. Пользователь user2 помечается как удалённый: softDeleteUser(user2)
2. Доктор отменяет appointment пациента user1: cancelAsDoctor(user1.appointment)
3. Отмена освобождает слот
4. Срабатывает promoteFromWaitlist(slotId)
5. Функция находит user2 в вейтлисте
6. Проверяет: есть ли у user2 активный appointment? — нет (он soft-deleted, его appointment был cancelled раньше)
7. Продвижение: создаётся новый pending appointment для user2, слот занимается
8. deleteSlot получает 409 SLOT_IN_USE

База данных после teardown:
-- appointment для пользователя которого "нет"
SELECT FROM appointments WHERE patientId = ?;
-- id: 47, patientId: 2 (deletedAt: '2026-05-20'), status: 'pending'

-- слот который нельзя удалить
SELECT isAvailable FROM slots WHERE id = ?;
-- isAvailable: 0

В production это означало бы: appointment в календаре врача для пациента, которого не существует. Без стандартного способа его отменить.

Root cause
softDeleteUser выглядел так:
async softDeleteUser(userId: number) {
await db.query(
'UPDATE users SET deletedAt = NOW() WHERE id = ?',
[userId]
);
}

Одна операция. Одна таблица. Я была уверена, что выставление deletedAt — это и есть «удалить пользователя». Что значит «удалить» для вейтлиста и очередей — отдельный вопрос, который не задавался. Slot_waitlist не трогал. promoteFromWaitlist проверял только одно условие перед созданием appointment:

const hasActiveAppointment = await db.query(
'SELECT id FROM appointments WHERE patientId = ? AND status = "active"',
[candidateId]
);

if (!hasActiveAppointment) {
// promote — create pending appointment
}

Нет активного appointment → можно продвигать. deletedAt нигде не проверялся. Soft-deleted пользователь был полноценным кандидатом для продвижения из вейтлиста.

Что значит «удалить» для каждого компонента

Вот как разные части системы понимали слово «удалён»:

У каждого компонента было своё определение «удалённый пользователь». У некоторых его не было вообще.

Почему это системная проблема, а не баг

«Баг» предполагает что где‑то написан неправильный код.

Здесь код promoteFromWaitlist написан правильно — он делает именно то для чего предназначен: находит первого в очереди без активного appointment и продвигает его.

Проблема в том, что операция «soft delete пользователя» не имела чёткой семантики в масштабах системы. softDeleteUser означал: «пометить пользователя удалённым в таблице users». А должен был означать: «удалить пользователя из системы» — что включает вейтлист, активные токены, очереди, и всё остальное что связано с этим пользователем.

Это разные операции.

Фикс

async softDeleteUser(userId: number) {
// сначала убрать из вейтлиста
await db.query(
'DELETE FROM slot_waitlist WHERE patientId = ?',
[userId]
);

// потом пометить удалённым
await db.query(
'UPDATE users SET deletedAt = NOW() WHERE id = ?',
[userId]
);
}

Порядок важен: если сначала выставить deletedAt, а потом чистить вейтлист — в промежутке может сработать promoteFromWaitlist. Race condition.

Архитектурный вывод

Soft delete — удобный паттерн. Но у него есть скрытая стоимость: операция «удалить» теперь означает разные вещи в разных частях системы.Запись в users помечена. Вейтлист не знает. Промоушн‑логика не знает.Каждый новый компонент который работает с пользователями должен явно учитывать deletedAt — или система будет накапливать такие ghost records. Когда в системе появляется soft delete — нужно ответить на вопрос: что значит «пользователь удалён» для каждого компонента который с ним работает? Не одного. Каждого.

Финальный вывод

Soft delete — это не удаление. Это изменение статуса одной записи в одной таблице. Всё что связано с пользователем: вейтлисты, сессии, токены, очереди — продолжает работать по старым правилам пока явно не почищено. Appointment для несуществующего пациента — это не баг promoteFromWaitlist. Это симптом того, что «удалить пользователя» не было определено как операция системы. Только как операция над одной записью.

Скрытое предположение

«Я решила, что „soft delete пользователя“ означает, что система перестаёт его видеть. На самом деле только одна таблица перестала его видеть. Остальные продолжали работать как обычно.»

Как это выглядит в реальной системе

Этот кейс нашёлся в тесте — не в production. Именно потому что fixture teardown прошёл через весь flow: soft delete → cancel → promote → delete slot. API тест на soft delete проверял только статус ответа. Интеграционный тест поймал состояние которое API тест не видел.

Код проекта: [GitHub]

Из серии «Тихие отказы в тест‑автоматизации»

Разборы таких кейсов — где тест находит то что API тест не видит — в Telegram-канале