Subversion Repositories SmartDukaan

Last modification

• Rev 37589 2026-09-11 17:30:03
• Author: amit

• Log message:

  Drive credit limits off the investment sweep; stop phantom limit writes
  
  Adds the 2-minute sweep schedule and points the limit recalculation at the
  partners whose base_value actually moved, instead of rescanning all 980 every
  20 minutes. Measured on production: 3 partners change per 2-minute window on
  average, peak 18.
  
  - ScheduledSkeleton: 2-min sweepPartnerInvestment, daily refreshAgedStockDaily
  at 00:20; the 20-min full pass is kept as a backstop for inputs base does not
  capture (risk, the SIDBI floor, hard_limit)
  - BatchScheduledTasks.sweepPartnerInvestment: sweep, then limits for changed
  bases only
  - calculateChangedPartnerLimits(restrictTo) to support that
  - scaleMoney(): round to paise before comparing and storing. The limit comes out
  of a double multiply, so 65123.7400 round-tripped as 65123.740000000005 and
  compareTo called it a change. 208 of 230 'changed' partners in one production
  run differed by under half a paisa, rewriting sd_credit_requirement and
  dtr.credit_account ~14,000 times a day for identical values and churning the
  SIDBI mirror. Real changes were never below a rupee, so 2dp cannot suppress one.
  - getFirstBillingDates: one grouped query instead of one per partner
  
  Credit limits for 24 partners will rise on the first sweep after deploy - that is
  the aged-Apple double-deduction correction landing (see r37588), not a defect.
  
  NOTE: cron is a standalone Spring Boot jar; the new schedules only fire once it
  is restarted with --spring.profiles.active=scheduled.