Skip to content

Conversation

@github-actions
Copy link

Automatic Release PR

This PR was automatically created after changes were pushed to develop.

Commits: 1 new commit(s)

Checklist

  • Review all changes
  • Verify CI passes
  • Approve and merge when ready for production

 & CVE-2025-15284 (#2925)

- Add body-parser 1.20.3 override to fix CVE-2024-45590 (DoS via deep nesting)
- Add qs ^6.14.1 override to fix CVE-2025-15284 (arrayLimit bypass)
- Disable automatic bodyParser in NestFactory.create() to remove unused urlencoded attack surface

Closes #2921
* feat(ref-reward): Add automatic liquidity pipeline for ref payouts

When ref reward payouts lack sufficient liquidity, automatically trigger
the LiquidityManagement pipeline (similar to BuyCrypto).

Changes:
- Add liquidityPipeline relation to RefReward entity
- Extend secureLiquidity() to check available liquidity
- Start pipeline via liquidityService.buyLiquidity() when deficit detected
- Set status to PENDING_LIQUIDITY before pipeline attempt (consistent with BuyCrypto)
- Process pending rewards when pipeline completes
- Reset to PREPARED on pipeline failure for automatic retry

Flow:
PREPARED → [liquidity check] → PENDING_LIQUIDITY → [pipeline complete] → READY_FOR_PAYOUT

* refactor: improve consistency of liquidity pipeline implementation

- Add pendingLiquidity() and resetToPrepared() entity methods to RefReward
  (consistent with existing entity method pattern like readyToPayout(), payingOut())
- Consolidate DB queries: load all rewards in single query instead of 3 separate
- Fix error handling: try/catch per individual reward instead of per asset group
  (consistent with ref-reward-out.service.ts pattern)
- Atomize pipeline updates: create pipeline first, then update rewards
  (avoids inconsistent state where rewards are PENDING_LIQUIDITY without pipeline)
- Remove misleading 'consistent with BuyCrypto' comment

* fix: change log level to warn for unexpected state

Rewards in PENDING_LIQUIDITY without pipeline should never occur
with atomic updates. This indicates legacy data or DB issues.

* feat: refactoring

* feat: added migration

---------

Co-authored-by: David May <david.leo.may@gmail.com>
@github-actions
Copy link
Author

github-actions bot commented Jan 13, 2026

⚠️ Non-Conventional Commits (1)

The following commits don't follow conventional commit format:

Expected: type(scope): description
Types: feat, fix, refactor, test, ci, docs, chore, perf, style, build, revert


⚠️ Security: 0 critical, 61 high vulnerabilities

TaprootFreak
TaprootFreak previously approved these changes Jan 13, 2026
#2929)

Kraken deposits with status='pending' (On Hold) were incorrectly being
counted as "arrived" in the toKraken pending balance calculation. This
caused the balance to show ~117k CHF less than actual, because:

- 50k CHF On Hold
- 30k CHF On Hold
- 40k EUR On Hold (~37k CHF)

These deposits have not yet been credited to the Kraken account and
should not be subtracted from the pending-to-Kraken amount.

Add status !== 'pending' filter to both CHF and EUR receiver exchange_tx
filters in getFinancialDataLog().
When processing refunds, user input (dto.refundTarget) should take priority
over the pre-filled value (refundData.refundTarget). This allows customers
to override the original IBAN when it's a Multi-Account IBAN that cannot
be used for refunds.

Changed:
- BankTxReturn refund: dto.refundTarget ?? refundData.refundTarget
- BuyCrypto bank refund: dto.refundTarget ?? refundData.refundTarget

Previously the logic was reversed, ignoring user-provided values when
the backend had a pre-filled refundTarget.
@TaprootFreak TaprootFreak merged commit c77c403 into main Jan 13, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants