wallets 0.4.1 → 0.4.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 06f03b26d96187aae331606ce523b158ad3303d3a0298cefdaf673d27f466bac
-  data.tar.gz: ecdb3cebac2c0b5ed8a83d14cf7a98e1b046ee59f3837bc2683bf3b2c0f8fe18
+  metadata.gz: d628d500b3ad1dfb236b6181fe30f976ae450aa9d4b8d8f5eb609969c6d59e66
+  data.tar.gz: 7c91562327a82f56429055df8f5b40e5644a226b7a83bfde9ed3cb68628faec0
 SHA512:
-  metadata.gz: b8041ad7293df22cf7a159bcc76b4c8186a2019be95250da10b7d9fe1760dcc4f06dd517a0c454c2ab229eb433036ab34c548a895b9ba176936266103477844a
-  data.tar.gz: c258acf79ced27d6e6acc0311bea40dec74683cc27bd2bd1ab246b7dd111600419d80608677c622207df3b1c8ae58a796296ac6d27b4fe3b9043e9f4ec192f06
+  metadata.gz: 8dd70a121851414b83efe8b1db52fff694a9c5b8a624135413d19c0e47d2a641538464d23879f3bbece40dacb87983cbe8af9f6ff6ed54d129127ef256de81c4
+  data.tar.gz: 903e0a69db10cf20c2502ff86a5914ffcbad2713cee1ae6e6f8591c53b52bae9fdfc61f61defe79130be9b5f9a496f849a6f6cbbaea2e5977e34a6e34751b82f

data/CHANGELOG.md

@@ -1,3 +1,9 @@
+## [0.4.2] - 2026-10-18
+
+### Fixed
+
+- **A rolled-back command no longer poisons the wallet or hold instance it wrote.** Every command starts by locking its row, and Rails refuses to lock a record with unsaved changes. When a command's savepoint or the caller's transaction was rolled back after the command had written the row (a block that spends inside a command and is then refused, a `transaction { wallet.debit(...); raise }` the caller rescues), Rails kept the cached `balance`, `ledger_revision` and `updated_at` the command had written in memory as unsaved changes, and the next command on the same wallet instance raised `RuntimeError: Locking a record with unpersisted changes is not supported` instead of running; a rolled-back release or capture did the same to its hold. The columns a command writes are the ledger's, not the caller's, and the lock reads the row again anyway, so `lock!` discards them first. A change the caller made to any other attribute is still refused, as Rails intends. Found by installing usage_credits 1.0.0 into a fresh app; its `spend_credits_on` is the first shape.
+
 ## [0.4.1] - 2026-10-18
 
 ### Documentation

data/lib/wallets/models/hold.rb

@@ -124,6 +124,22 @@ module Wallets
     # nothing. Why it ended is recorded next to why it began, never over it.
     #
     #   hold.release!(reason: "cleared_by_operator", metadata: {actor_id: operator.id})
+    # The columns a release or a capture writes on the hold row; the caller
+    # never sets them after the hold is placed.
+    COMMAND_WRITTEN_COLUMNS = %w[released_at release_reason release_metadata capture_transaction_id updated_at].freeze
+    private_constant :COMMAND_WRITTEN_COLUMNS
+
+    # A release or a capture locks the hold row, and Rails refuses to lock a
+    # record with unsaved changes: a rolled-back release or capture leaves
+    # what it wrote in memory as unsaved changes, so retrying it on the same
+    # instance would raise. Those columns are the command's, and the lock
+    # reads the row again, so they are discarded first (see
+    # `Wallets::WalletBase#lock!`).
+    def lock!(lock = true)
+      restore_attributes(changed & COMMAND_WRITTEN_COLUMNS) if persisted?
+      super
+    end
+
     def release!(reason: nil, metadata: {})
       raise InvalidHold, "Only a saved hold can be released" unless persisted?
 

data/lib/wallets/models/wallet.rb

@@ -66,6 +66,25 @@ module Wallets
     ARRIVAL_HOLD_OPTIONS = %i[category until metadata].freeze
     private_constant :ARRIVAL_HOLD_OPTIONS
 
+    # The columns the ledger itself writes on the wallet row
+    # (`refresh_cached_balance!`); the caller never sets them.
+    LEDGER_WRITTEN_COLUMNS = %w[balance ledger_revision updated_at].freeze
+    private_constant :LEDGER_WRITTEN_COLUMNS
+
+    # Every command starts by locking the wallet row, and Rails refuses to
+    # lock a record with unsaved changes. A rolled-back command leaves
+    # exactly that behind: the cached balance, the revision and `updated_at`
+    # it had written stay in memory, marked as unsaved changes, once its
+    # savepoint or the caller's transaction is rolled back, and the next
+    # command on the same instance would raise. Those columns are the
+    # ledger's, not the caller's, and the lock reads the row again anyway,
+    # so they are discarded first. A change to any other attribute is the
+    # caller's, and Rails' refusal stands.
+    def lock!(lock = true)
+      restore_attributes(changed & LEDGER_WRITTEN_COLUMNS) if persisted?
+      super
+    end
+
     self.table_suffix = "wallets"
 
     # =========================================
@@ -1642,12 +1661,13 @@ module Wallets
     # the balance did not move, because `touch` writes nothing under
     # `no_touching`.
     #
-    # `update!` rather than assigning and then saving: if the command's
-    # savepoint rolls back afterwards, Active Record leaves the wallet with no
-    # pending changes, so its next command can lock it. It is clean, not
-    # restored: it keeps the rolled-back values in memory until that lock
-    # reloads the row. Assigning first would leave them pending instead, and
-    # no later command could lock the wallet.
+    # `update!` rather than assigning and then saving, so nothing sits pending
+    # between commands. A rollback can still leave these columns pending:
+    # once the real transaction, or a savepoint the caller opened, rolls
+    # back, Active Record restores the values this write left in memory as
+    # unsaved changes. `lock!` discards exactly those (LEDGER_WRITTEN_COLUMNS)
+    # before locking, so the next command can lock the wallet and reads the
+    # row again.
     def refresh_cached_balance!
       available = current_balance
 

data/lib/wallets/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Wallets
-  VERSION = "0.4.1"
+  VERSION = "0.4.2"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: wallets
 version: !ruby/object:Gem::Version
-  version: 0.4.1
+  version: 0.4.2
 platform: ruby
 authors:
 - rameerez