Subversion Repositories SmartDukaan

Last modification

• Rev 37588 2026-09-11 17:29:49
• Author: amit

• Log message:

  Serve partner investment from a 2-minute snapshot instead of a 3-hour cache
  
  getInvestment() was @Cacheable on a 3-hour Redis cache that addAmountToWallet
  evicted but consumeAmountFromWallet did not. A partner whose advance payment was
  swept straight to a loan had the money counted twice - once as a still-cached
  wallet balance, once as the reduced utilisation - overstating their credit limit
  by the payment x their tier until the cache expired.
  
  Replaced with fofo.partner_investment, refreshed every 2 minutes by
  PartnerInvestmentSweepService. Every coupled term is read in one pass, so wallet
  and utilisation (and in-stock and aged-Apple) can never come from different
  moments. A shorter TTL would only have made the error rarer - it scales with the
  payment, not the delay.
  
  - PartnerInvestment entity/repository + partner_investment_snapshot.sql
  - PartnerInvestmentSweepService: 9 batched reads, stores base_value for change
  detection, refreshes aged-Apple for partners whose stock moved intra-day
  - getInvestment/getInvestmentsForFofoStores both read the snapshot, so the two
  paths no longer disagree; live compute retained as fallback
  - selectActivatedStockAmountByFofoIds: batches an N+1 that cost 233ms x 1690
  partners (6.6 min -> 1.0 s)
  - getFirstBillingDates: batches another N+1 (4.6 s -> 0.67 s)
  - selectPendingGrnOrders(List) now applies the same SD_START_DATE floor as the
  single-partner overload; the two were reporting different GRN-pending
  - selectPartnerStockValueMap takes excludeActivated: an activated Apple handset
  held past the aging window was added once to in-stock and subtracted twice
  (activated stock, then the aged haircut). 90 units, 24 partners, Rs 65.19 lakh
  double-deducted. Live-demo passes false - no overlap there.
  - applyManualAdjustment: routes the two hand-rolled admin wallet adjustments
  through WalletServiceImpl so they take the FOR UPDATE lock
  - add_idx_order_grn_pending.sql: covering index, GRN query 1320ms -> 514ms