Skip to content

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

@viribus-issue-bot

Description

@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.


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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions