[ING-476] fix(lifetime_usage): retry wallet lock inline

[mariohd]

Context

When a subscription activity is processed, UsageMonitoring::ProcessSubscriptionActivityService runs the lifetime-usage recalculation inline via RecalculateAndCheckJob.perform_now(lifetime_usage, current_usage:). current_usage is a SubscriptionUsage struct, which ActiveJob cannot serialize (it is only safe under perform_now, which does not serialize arguments).

The job retries wallet lock conflicts (ActiveRecord::StaleObjectError, BaseLockService::FailedToAcquireLock) through ActiveJob's retry_on. When a wallet optimistic-lock conflict happens during the inline run, retry_on tries to re-enqueue the job for a retry, which serializes the arguments and fails on the SubscriptionUsage struct. The result is a misleading ActiveJob::SerializationError: Unsupported argument type: SubscriptionUsage that masks the real underlying StaleObjectError on Wallet.

Solution

Retry the lock conflict in-process on the inline path so it never reaches ActiveJob's retry_on. The async perform_later path (no current_usage) keeps relying on retry_on, so it does not hold a worker while waiting between attempts.

• Split perform into two paths: with current_usage present, wrap the work in an in-process retry (MAX_LOCK_RETRY_ATTEMPTS, rand(0...MAX_LOCK_RETRY_DELAY) backoff); otherwise call the services directly and let retry_on handle retries.
• On exhaustion, raise a dedicated InlineLockRetryExhausted error that is intentionally not listed in retry_on. It is raised with the cause chain broken (cause: nil) because retry_on also matches an exception's cause — otherwise the wrapped lock error would still trigger a retry and the same serialization failure. The original error is preserved in the message for observability.

Testing

• New specs cover the inline current_usage path for both lock error classes: retries then resolves without raising ActiveJob::SerializationError, and exhausts to InlineLockRetryExhausted (never SerializationError).
• Existing retry_on (async) and discard_on behavior is unchanged and still covered.
• RecalculateAndCheckJob spec: 13 examples, 0 failures. ProcessSubscriptionActivityService spec: 12 examples, 0 failures. RuboCop clean on the changed files.

[toommz]

Why not just call .to_h before enqueuing, and reconstruct the struct in the service when it is a Hash? It would save us from this inline retry logic 🤔

I really think the real problem here is passing a non-serializable object to our job layer.

[mariohd]

@toommz
https://github.com/getlago/lago-api/pull/5940/changes#diff-70f317eb4d1bc8c374d8ee7af381d011551a621fc57cf8221bfd385211871576R32

# NOTE: do not pass current usage with perform_later as it will be a huge JSON

The current_usage tends to be a super huge hash and if we serialize it, it may break the job schedule as well, so it has to be executed inline.
Here it mentions about perform_later, a retry is a form of perform_later, so we shouldn't serialize the params.
In order to have the retries for inline execution, we need to catch the exception and run inline again; checking if the max attempts wasn't reached.