problem

claim_rewards iterates the global PendingConversions map and converts each pending asset to the reward asset before paying out shares. it only tolerates two conversion errors — ConversionMinTradingAmountNotReached and ConversionZeroAmountReceived — and reverts the whole call on anything else.

the v49 fee-flow refactor moved conversion to ConvertViaOmnipool, which dropped the old explicit min-amount pre-check (that returned ConversionMinTradingAmountNotReached). it now calls Omnipool::sell directly → for a pot balance below MinTradingLimit (1_000 raw units) it propagates the raw pallet_omnipool::Error::InsufficientTradingAmount, which is not in the tolerated set.

result → any sub-MinTradingLimit dust balance of a non-reward asset in PendingConversions makes claim_rewards revert:

• since extrinsics run before on_idle, a dust entry left by a trade earlier in the same block blocks every claim_rewards in that block
• weaponizable as a cheap, permissionless same-block front-run grief against reward claimers (self-link + tiny linked trade tuned so the 5% slice lands in [1, 999] of an obscure asset)
• also causes incidental spurious claim failures for honest users
• no funds lost — rewards stay claimable next block — but it's a real correctness/griefing defect

regression vs v48: the old convert returned ConversionMinTradingAmountNotReached for sub-min amounts (which the claim loop tolerated); the new converter returns InsufficientTradingAmount, and the claim loop's tolerated-error list was never updated.

fix

make the claim loop best-effort, identical to the sibling on_idle hook (which already does let _ = T::Convert::convert(...)): skip an un-convertible slice instead of reverting, and drop the entry either way. a skipped conversion now emits a ConversionFailed { asset_id, reason } event (in both claim_rewards and on_idle) so it is surfaced rather than silently swallowed — mirroring the fee-processor.

• the conversion is genuinely best-effort → funds stay in the pot, reward accounting is share-based and independent of the swap, and the asset re-queues on the next fee
• removes the claim_rewards ↔ on_idle tolerance divergence by construction

why not extend the exact-match list instead?

the alternative is to keep the if let Err propagation and add the new tolerated variants (InsufficientTradingAmount, ConversionFailed, PriceNotAvailable). rejected because:

• it's what caused this bug. the tolerated list was coupled to the converter's exact error variants; when the converter impl changed, the list silently went stale and started reverting. any new list carries the same drift risk on the next converter change.
• it can't be written cleanly here. pallet-referrals constrains its converter to Convert<…, Error = DispatchError> and does not depend on pallet-omnipool/pallet-fee-processor. matching their error variants would mean either adding those deps (bad layering for a generic rewards pallet) or matching raw DispatchError::Module discriminants (fragile).
• the swallow-all matches on_idle, which already abandoned exact-match — so both cleanup paths now behave identically.

the visibility that exact-match gave (surfacing an unexpected converter error rather than dropping it) is preserved by the ConversionFailed event, without re-introducing the coupling.

test

claim_rewards_should_succeed_when_pending_asset_balance_is_below_min_trading_limit → a 500-unit (sub-min) DAI dust entry no longer blocks an unrelated user's claim, and a ConversionFailed event is emitted for it. the mock AssetConvert now models the production min-trading-limit rejection (returns a non-referrals error for sub-min amounts), gated behind a new with_convert_min_amount builder defaulting to disabled so existing tests are unaffected.

• red before the one-line fix, green after; all 60 referrals tests pass

versions

• pallet-referrals 1.6.0 → 1.6.1
• runtime spec_version 426 → 427, hydradx-runtime 426.0.0 → 427.0.0