Renovação ignorava filiação com pagamento pendente e sobrepunha o período vigente
O que aconteceu
Durante uma campanha, o checkout permitiu que terapeutas com pendência financeira (IBFT) comprassem a renovação da filiação — uma flexibilização pensada para outros tipos de produto, mas que não diferenciava o tipo de compra. Quando isso acontecia, o sistema criava uma nova filiação começando na data da compra em vez de continuar depois do fim da vigência já paga anteriormente, sobrepondo os dois períodos. Foram identificados 2 casos, corrigidos manualmente via console.
Causa raiz
Ao calcular a data de início de uma nova filiação, o sistema buscava a filiação mais recente com payment_status: paid e vigência em andamento para encadear a partir dela. Uma filiação pending ou overdue — mesmo com vigência real em andamento (ex.: de ago/2025 a ago/2026) — não era encontrada por essa busca, então o sistema entendia que não havia nada em andamento e começava a nova filiação a partir de hoje.
Esse é o segundo caso desse mesmo padrão no mesmo trecho de código: um fix anterior já havia removido a exigência de aprovação de admin pelo mesmo motivo (filiação paga mas ainda não aprovada era ignorada).
Correção
A busca passou a considerar qualquer filiação com vigência em andamento, independente do status de pagamento, exceto refunded (filiação estornada nunca representa uma vigência real). A lógica de checkout/campanha que permitiu a compra com pendência não foi alterada — está fora deste sistema.
Como evitar
Ao buscar “a filiação vigente anterior” de um usuário para encadear datas, o critério certo é a vigência em si (valid_until >= hoje) combinada apenas com a exclusão de estados que invalidam o período (como refunded) — não a exigência de um estado “ideal” (paid, aprovado por admin, etc.). Estados intermediários como pendente ou atrasado ainda representam um período real que o usuário está usando, e ignorá-los cria sobreposição de vigências.