A investigação vai camada por camada, do que o usuário viu até o dado gravado:

Reproduzir com uma conta de teste, com o painel de rede aberto. Reproduziu? Se não, colete tudo que possa diferir (Fundamentos, Módulo 5).
A requisição de criação: que status voltou no POST? Se veio 201, o que tem no corpo, veio um id?
O dado existe? No banco: SELECT * FROM pedidos WHERE id = <id devolvido>. Três desfechos possíveis, e cada um aponta para um lugar diferente:
- não existe → a API respondeu sucesso sem gravar: defeito na escrita ou transação que não commitou;
- existe, mas com cliente_id errado ou nulo → gravou no lugar errado, e por isso não aparece no histórico daquele usuário;
- existe e está correto → o problema está na leitura, não na escrita.
Se está correto no banco: chamar direto GET /pedidos?cliente_id=X e comparar com SELECT * FROM pedidos WHERE cliente_id = X. Se a API devolve menos, o defeito está no filtro, na paginação, ou em cache.
Procurar o padrão: é só esse pedido? SELECT COUNT(*) FROM pedidos WHERE cliente_id IS NULL, ou pedidos apontando para cliente inexistente: se houver muitos, o defeito é sistêmico e a prioridade sobe.
Relatar com o id do pedido, a resposta do POST, a linha do banco e a resposta do GET lado a lado. Com essa evidência, quem corrige não precisa investigar de novo.

O ponto central da resposta: separar escrita de leitura. "Não aparece no histórico" tem duas causas completamente diferentes, e a consulta ao banco é o que decide qual das duas é, em um minuto, em vez de um dia.

Prova do Módulo 4