⚡ Cliente de API iFood

O IfoodApiClient é o coração da comunicação do projeto. Ele estende uma HttpSession personalizada que já possui lógica de retry e timeouts configurados para 15 segundos.

🔑 Identificação do Dispositivo (Device ID)

Para evitar bloqueios por comportamento automatizado, o sistema utiliza a geração dinâmica de device_id.

Localização: ifood/utils/device.py
Lógica: Gera um UUID v4 único na inicialização do aplicativo se nenhum valor fixo for encontrado no .env.
Header: x-ifood-device-id.

🔄 Polling & Eventos

O sistema monitora a fila de eventos do iFood continuamente.

Intervalo: 30 segundos (configurável em dashboard.py).
Deduplicação: O sistema mantém um cache local e uma hierarquia de estados para evitar processar o mesmo pedido várias vezes.

Hierarquia de Estados (Status Rank)

Para garantir a estabilidade da interface, implementamos um ranking de status. O sistema recusa atualizações que tentem “retroceder” o estado de um pedido:

PLACED (Rank 0)
CONFIRMED (Rank 1)
CANCELLED / DISPATCHED (Rank 2)
CONCLUDED (Rank 3)

🛠️ Métodos Principais

`confirm_order(order_id)`

Envia o sinal de aceite para o iFood. O status visual no dashboard muda instantaneamente para CONFIRMED.

`request_cancellation(order_id, cancel_code, reason)`

Solicita o cancelamento. Utilizamos a classe CancellationCode (Enum) para garantir que apenas códigos válidos sejam enviados:

501: Problemas de sistema na loja
502: Pedido duplicado
503: Item indisponível
(E outros 8 códigos oficiais)

📦 Persistência

Cada pedido recebido é persistido em um arquivo JSON na pasta src/tmp (ou conforme configurado). Isso permite auditoria offline e integração com outros sistemas de retaguarda.

Para detalhes sobre como o token de acesso é gerado, veja o Guia de Autenticação.