Início / Blog / Dinheiro

Por que editar uma despesa deve refazer a divisão

29 de agosto de 2026 · 9 min de leitura · Dimesum Engineering

Os padrões de uma edição são bugs de dinheiro, então o Dimesum torna participants e split_type obrigatórios em todo PATCH de despesa, junto do base_version que rejeita uma edição desatualizada em vez de mesclá-la.

Corrigir um erro de digitação não deveria mudar quem deve dinheiro. No Dimesum, editar uma despesa compartilhada refaz toda a divisão. participants e split_type são obrigatórios em todo PATCH, e uma edição que omite qualquer um deles volta com 400 em vez de preencher um padrão. Os padrões de criação são todos os membros atuais e uma divisão igual, que numa edição são bugs de dinheiro.

Duas falhas tornam o caso concreto. Um colega de apartamento que entrou em agosto é puxado para o jantar de julho, porque "todos os membros atuais" é avaliado quando a edição chega, não quando a despesa foi gravada. Uma divisão de aluguel deliberada de 70/30 achata para 50/50, porque um split_type ausente significa EQUAL. Nenhuma das falhas gera um erro, e ambas movem dinheiro de verdade.

Os padrões de criação descrevem uma despesa nova, não uma antiga

No momento da criação, os padrões são honestos. O autor está vendo o grupo como ele está, e uma divisão igual entre todos é o caso comum, então o Dimesum preenche os dois. A despesa armazena suas entradas em vez de apenas seus resultados: splits.percent_bp, splits.weight e splits.exact_minor guardam o que o usuário digitou, então uma edição posterior pode reabri-la.

Uma edição é um ato diferente. A mesma despesa pode ser corrigida semanas depois, quando um novo colega de apartamento entrou ou um membro fantasma foi reivindicado. A composição do grupo é um alvo móvel e a divisão não. Reutilizar os padrões de criação pede que o grupo de hoje responda uma pergunta que a despesa antiga já respondeu.

A recusa em adivinhar não é novidade aqui. Uma despesa com vários pagadores também deve refazer seus pagadores. soleStoredPayer reutiliza o pagador armazenado apenas quando a despesa tem exatamente um, então uma edição que fica em silêncio sobre dois pagadores é recusada em vez de reatribuída. Uma edição que não diz nada sobre pagadores mantém o próprio pagador da despesa, nunca a pessoa que está editando.

A API recusa uma edição que não refaz sua divisão

A verificação do gateway roda antes de qualquer dinheiro ser calculado. Quando participants está vazio ou split_type está em branco, a requisição volta com 400 com o código invalid_expense e a mensagem "an edit must restate the split: participants and split_type are required". O serviço de despesas repete a regra em validateAmend, então um chamador que alcança o serviço por outro caminho encontra a mesma recusa.

A moeda pertence à mesma família de recusas. Uma edição não pode redenominar uma despesa, porque uma linha de saldos guarda uma moeda por membro. O lado de escrita rejeita a mudança, e o livro-razão append-only estaciona tal alteração se alguma vez chegar a ele. Recusar na porta impede que as duas metades discordem.

Uma edição desatualizada é rejeitada para seu autor, nunca mesclada

base_version é a outra metade do contrato. Todo PATCH carrega a versão que seu autor leu, e checkTransition a compara com a linha que a transação acabou de bloquear. Igual, e a edição se aplica na versão mais um. Diferente, e o chamador recebe HTTP 409 com o código stale_version.

Mesclar é a alternativa tentadora, e está errada. Duas edições numa despesa são duas declarações completas do que a conta significa. Mesclá-las produz uma terceira declaração que ninguém escreveu, com parcelas que nenhum dos autores reconheceria. A rejeição devolve o conflito à única pessoa que pode resolvê-lo.

Idempotência e concorrência são mantidas separadas de propósito. A inserção da revisão roda antes da verificação de versão, porque uma edição repetida carrega a versão base que leu originalmente, que agora está desatualizada. Uma repetição deve ser lida como repetição e não como conflito, então revision_id responde primeiro e retorna o resultado armazenado.

A resposta já carrega o que a próxima edição precisa

Exigir mais campos num PATCH só é justo se um cliente puder obtê-los de forma barata. Toda resposta de despesa carrega version, então um cliente que acabou de gravar uma despesa pode editá-la sem uma segunda leitura. A resposta de criação, a resposta de alteração e cada linha de lista carregam o mesmo campo.

Para o cliente que não acabou de gravar a despesa, GET /v1/groups/{id}/expenses/{id} retorna a versão, as parcelas calculadas e as entradas por trás delas. As entradas voltam sob os mesmos nomes que um PATCH aceita: participants, split_type, percents, weights, shares, items, pools. Um cliente lê um formato e o envia de volta com edições, em vez de traduzir entre dois vocabulários para uma conta.

A simetria importa mais para divisões que não podem ser reconstruídas. Uma divisão PERCENT ou uma conta detalhada por item não pode ser refeita apenas a partir de suas parcelas resolvidas, porque o arredondamento já foi aplicado e os basis points e os itens de linha se foram. Os instantâneos de revisão também carregam as entradas, então a folha de histórico pode mostrar o que foi detalhado em qualquer versão passada.

Obrigatório agora, porque uma exigência não pode ser adicionada depois

Exigir um campo no primeiro dia é uma decisão sobre o futuro, não sobre hoje. Afrouxar um campo obrigatório depois é retrocompatível: os clientes já o enviam, e o servidor passa a aceitar requisições sem ele. Adicionar uma exigência depois quebra todo cliente que dependia do padrão antigo.

Então a direção é escolhida uma vez, cedo. O Dimesum exige participants, split_type e base_version numa edição enquanto o número de clientes ainda é pequeno o suficiente para mudar. Se um padrão seguro para edições um dia for encontrado, os campos se tornam opcionais e nada já entregue para de funcionar.