-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Issue open by Mark Shidran via group-chat message.
ОБНОВЛЕННЫЙ Отчет о проблеме с очисткой данных в API проката
Дата: 23.10.2025
Автор: GitHub Copilot
Кому: Команда разработки бэкенда
Краткое описание проблемы:
Невозможно полностью и предсказуемо очистить базу данных от тестовых данных. Операции удаления типов предметов (ItemType) блокируются из-за "фантомных" ссылок на уже удаленные экземпляры предметов (Item). Это указывает на вероятную рассинхронизацию данных или агрессивное кеширование на стороне бэкенда.
Основная гипотеза:
После успешного выполнения запроса DELETE /rental/item/{id}, запись об экземпляре предмета удаляется не полностью. Другие части системы (в частности, эндпоинт PATCH /rental/itemtype/available/{id}) продолжают видеть "фантомную" ссылку на удаленный объект, что приводит к ошибкам и логическому тупику.
Доказательная база (последовательность запросов)
Шаг 1: Провоцируем ошибку, чтобы найти "проблемный" Item.
Выполняем PATCH запрос для обнуления доступности ItemType с ID 1.
Запрос:
curl -X PATCH "https://api.test.profcomff.com/rental/itemtype/available/1?count=0" \
-H "Authorization: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
Ответ сервера (ошибка 404):
{
"status": "Error",
"message": "Object Item obj_id_or_name=7 not found",
"ru": "Объект Item с идентификатором 7 не найден"
}
Вывод: Система сообщает, что проблема связана с Item с ID 7.
Шаг 2: Удаляем "проблемный" Item.
Выполняем DELETE запрос для Item с ID 7.
Запрос:
curl -X DELETE "https://api.test.profcomff.com/rental/item/7" \
-H "Authorization: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
Ответ сервера (успех 200):
{
"status": "Success",
"message": "Object Item id=7 was deleted",
"ru": "Объект Item с id=7 был удален"
}
Вывод: На этом шаге система подтверждает, что объект успешно удален.
Шаг 3: Повторно пытаемся удалить тот же Item.
Чтобы убедиться, что объект действительно удален, повторяем DELETE запрос.
Запрос:
curl -X DELETE "https://api.test.profcomff.com/rental/item/7" \
-H "Authorization: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
Ответ сервера (ошибка 404):
{
"status": "Error",
"message": "Object Item obj_id_or_name=7 not found",
"ru": "Объект Item с идентификатором 7 не найден"
}
Вывод: Система подтверждает, что объекта с ID 7 больше не существует.
Шаг 4: Повторно провоцируем ошибку (ключевой шаг).
Теперь, когда мы уверены, что Item с ID 7 удален, повторяем самый первый PATCH запрос.
Запрос:
curl -X PATCH "https://api.test.profcomff.com/rental/itemtype/available/1?count=0" \
-H "Authorization: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
Ответ сервера (снова та же ошибка 404):
{
"status": "Error",
"message": "Object Item obj_id_or_name=7 not found",
"ru": "Объект Item с идентификатором 7 не найден"
}
Вывод: Это критическое противоречие. Система утверждает, что Item с ID 7 не существует, но при этом операция с родительским ItemType срывается именно из-за "фантомной" ссылки на этот удаленный Item.
Итоговое заключение и рекомендации
Проблема не в том, что предметы не удаляются, а в том, что система ведет себя так, как будто они все еще существуют. Это делает невозможным написание надежного скрипта для очистки данных.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status