fix(serverust-events): liberar lock InProgress após falha do IdempotencyLayer

[cursor]

Bug e impacto

Quando um handler SQS falhava com IdempotencyLayer ativo, o lock InProgress permanecia gravado pelo TTL (default 24 h). Na redelivery do SQS (visibility timeout de segundos/minutos), try_acquire retornava InProgress e o handler não era reexecutado — a mensagem podia ir para a DLQ da AWS sem processamento bem-sucedido.

Cenário concreto: handler transiente falha → lock InProgress 24 h → SQS redeliver em ~30 s → erro "already in progress" em loop até maxReceiveCount → DLQ sem sucesso.

Causa raiz

IdempotencyLayer chamava complete() apenas em sucesso do handler, mas não liberava o lock em falha (nem quando complete() falhava após sucesso).

Correção

• Novo método IdempotencyStore::release (InMemory + DynamoDB).
• IdempotencyLayer chama release após erro do handler ou falha ao gravar Completed.
• Testes de regressão: redelivery SQS após falha transiente, release no store.

Validação

cargo test -p serverust-telemetry --test idempotency_lock
cargo test -p serverust-events --features sqs --test sqs_idempotency
cargo test -p serverust-events --features sqs --test sqs_tower

Todos passaram (21 testes).

  

[JaimeJunr]

Fechado como duplicata. Os PRs #23, #24, #25 e #26 foram gerados de forma independente pelo scan semanal e corrigem exatamente o mesmo bug (lock InProgress não liberado após falha do handler no IdempotencyLayer).

O #24 foi escolhido como base por ser o único que combina as três propriedades desejáveis:

• release remove apenas InProgress — não apaga registro Completed
• DeleteItem condicional no DynamoDB (#state = :in_progress), tratando ConditionalCheckFailedException como sucesso
• teste de regressão que exige duas execuções reais do handler, não só reacquisition do lock

O teste de falha de complete() do #23 foi portado para o #24. Nada mais desta branch se perde.