Удаление объектов не работает

[viribus-issue-bot]

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.

---

Итоговое заключение и рекомендации

Проблема не в том, что предметы не удаляются, а в том, что система ведет себя так, как будто они все еще существуют. Это делает невозможным написание надежного скрипта для очистки данных.

[petrCher]

ручка patch itemtype/available/{id}
ввожу 1 и 1 в параметры запроса, вылетает
Error: response status is 404
Response body
Download
{
"status": "Error",
"message": "Object Item obj_id_or_name=34 not found",
"ru": "Объект Item с идентификатором 34 не найден"
}
изучить что не так. как минимум сейчас нелогично в ручке для itemtype получать инфу о мнимом item

[petrCher]

Выполнено