Renovação sem reaprovação zerava a data de validade exposta pela API
O que aconteceu
Uma associada renovou sua filiação (pagamento em dia, validade até 2027) mas o endpoint apolo_membership continuava retornando valid_until/valid_until_timestamp como null, como se ela não tivesse filiação nenhuma. Isso fez o trg-club-api entender que ela não tinha mais filiação ativa e rebaixar a assinatura PRO dela, mesmo em dia com o pagamento.
Causa raiz
Toda renovação cria uma nova Membership (mesmo register_number), e essa nova filiação nasce sem aprovação de admin nem cartão emitido, a menos que o usuário já tenha a flag issued_definitive_card (só existe para quem foi aprovado depois de um certo marco/data — não há backfill para membros mais antigos). O endpoint escolhia a filiação mais recente entre as aprovadas, então pegava uma filiação antiga e já vencida em vez da nova (paga, mas ainda não reaprovada) — e por isso valid_until/valid_until_timestamp vinham null (esses campos só eram preenchidos quando o acesso já estava liberado).
Correção
O endpoint passou a escolher a filiação paga mais recente (não a mais recente aprovada), e valid_until/valid_until_timestamp passaram a sempre refletir a data real da filiação selecionada, independente do status de aprovação. O campo apolo_access_status (usado para liberar acesso físico/cartão) não foi alterado — continua exigindo aprovação manual ou cartão emitido, exatamente como antes.
Como evitar
Ao expor dados de uma entidade que tem um “gate” de aprovação (aqui, apolo_access_permitted?), separar os campos que descrevem fatos (datas, valores pagos) dos campos que descrevem permissão (apolo_access_status). Um consumidor externo (como o trg-club-api) que só precisa saber “até quando essa pessoa pagou” não deveria depender de um gate de aprovação interno de outro sistema — isso acopla indevidamente processos administrativos internos a decisões de negócio de terceiros.
Desdobramento
Essa correção introduziu um segundo problema: com a seleção por “mais recente paga”, a renovação antecipada (filiação futura, ainda não aprovada) passou a ser sempre a escolhida, bloqueando o acesso de 192 membros no Apolo. A regra final compõe a resposta a partir de duas filiações — ver R-001.