Средний

4 мин

7.2K

Как удалённый пользователь получил 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]
);
}

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

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