| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 36362 |
18 h 41 m |
amit |
/trunk/profitmandi-dao/src/main/ |
Make fofo_order creation idempotent on (fofo_id, invoice_number)
Fixes insert-intention gap-lock deadlocks on idx_invoice_number observed in
SHOW ENGINE INNODB STATUS at 2026-04-22 13:01:54 — two concurrent requests
inserting the same invoice_number for the same customer (client retry /
upstream webhook retry pattern).
- OrderServiceImpl.createAndGetFofoOrder: select-then-insert idempotency.
Fast path returns existing row if already created; slow-race path catches
DataIntegrityViolationException and re-selects the winner's row.
- add_uk_fofo_order_fofo_invoice.sql: adds UNIQUE KEY (fofo_id, invoice_number)
so the loser of a concurrent-insert race gets a clean DIVE instead of a
silent duplicate row (pre-check showed zero existing dup groups, safe).
findExistingFofoOrder wraps the repo call to swallow the repo's declared
ProfitMandiBusinessException — the impl actually returns null on not-found
(constructs an exception but never throws), so the swallow matches reality. |
|
| 36359 |
20 h 3 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
rbm rating dashboard view commited |
|
| 36357 |
20 h 47 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Fix background-thread 'no session' error in DB guard. CronBatchRepository.selectRunningForOffer uses getCurrentSession() which needs an open tx; when OfferBatchService.processOfferWithBatch is called from the async worker thread (no outer tx), the guard query crashed with 'Could not obtain transaction-synchronized Session'. Offer 8819 submit succeeded but the background run died at the guard — before createBatch, so no cron_batch / cron_batch_item rows. Added CronBatchService.findRunningForOffer wrapping the repo call in @Transactional(readOnly=true); orchestrator calls the service method instead of repo directly. Matches the pattern used by loadOfferRequest / createBatch / calculate*Payouts — every caller opens its own tx. |
|
| 36356 |
21 h 14 m |
ranu |
/trunk/ |
rbm rating dashboard view commited |
|
| 36355 |
21 h 50 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/offers/ |
Skip already-paid partners before creating cron_batch_item rows. Adds hasRemainingSellinPayout / hasRemainingOfferPayout predicates on OfferProcessingHelper that mirror the amount calc in processPartner*Payout. Orchestrator filters partnerPayouts through these before createBatch — partners whose serials are fully paid (amount=0 after subtracting serialNumberPaid) are excluded entirely. Reruns of a completed offer now create no batch at all (log says 'all N eligible partners already fully paid, skipping batch'); partial reruns log filtered count. Avoids audit-trail noise of SUCCESS items that did zero work. |
|
| 36354 |
22 h 14 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
DB-backed concurrent-run guard for OfferBatchService.processOfferWithBatch. Adds CronBatchRepository.selectRunningForOffer(offerId) — single HQL query for RUNNING cron_batch rows named processSellinOffer-N or processActivationOffer-N. OfferBatchService early-returns (with a log) if any such row exists. Covers the three gaps the in-memory guard can't: JVM restart, multi-JVM, cron CLI + user click racing. Applies to both sync (cron --processOffersWithBatch) and async (/offer/process HTTP) paths. |
|
| 36351 |
23 h 30 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Add CronBatchRepository.selectRecent(limit) and CronBatchItemRepository.selectByBatchId(batchId) for admin batch review UI. selectRecent returns most-recent-first via selectAllOrderByDescPaginated('id'); selectByBatchId uses selectAllByEqualOrderByDesc. |
|
| 36350 |
23 h 33 m |
aman |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/ |
Fix:Add brand commitment, ASM details, and finance option in WOD initiation email |
|
| 36347 |
23 h 47 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/offers/ |
Add submitBatchAsync for fire-and-forget /offer/process — schedules processOfferWithBatch on a bounded background pool (3 daemon threads) and returns immediately with a human-readable message. In-memory ConcurrentHashMap.newKeySet() per-offerId guard prevents duplicate concurrent runs for the same offer (the scenario that caused offer 8802 deadlocks). Sync processOfferWithBatch kept unchanged for cron CLI (--processOffersWithBatch). |
|
| 36346 |
1 d 0 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
rbm rating dashboard view commited |
|
| 36342 |
1 d 2 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/offers/ |
Add OfferBatchService orchestrator — shared batch entrypoint for offer processing, used by cron CLI and /offer/process controllers. Loads offer, calls calculate*Payouts (read), creates cron_batch, runs each partner in REQUIRES_NEW via OfferProcessingHelper, finalizes batch and emails on partial failure. No @Transactional on the class — must not carry outer tx. |
|
| 36337 |
1 d 2 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Move CronBatchService and OfferProcessingHelper from cron to dao so web/fofo can reuse the batch infra; fix empty-IMEI NPE in getInventoryItemMap that broke /offer/process for partners with no billed/scanned serials |
|
| 36336 |
1 d 2 h |
ranu |
/trunk/ |
sales dispostion updated |
|
| 36335 |
1 d 20 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
rbm rating dashboard view commited |
|
| 36334 |
1 d 20 h |
ranu |
/trunk/ |
rbm rating dashboard view commited |
|
| 36333 |
1 d 20 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Fix IllegalStateException: drop 'unless' when using @Cacheable(sync=true)
Spring Cache rejects @Cacheable with both sync=true AND an 'unless' attribute,
throwing IllegalStateException on every invocation. Surfaced in production log
on smartdukaan — MonitorController.todayPORBM:739 was returning 500 on 40
observed calls this session.
Dropped 'unless'. Caching an occasionally-empty List for 5 min is harmless:
months with no sales produce an empty result, which is cheaper to re-query
after 5 min than to keep special-casing. The real fix driver for sync=true
(stampede protection) is preserved. |
|
| 36332 |
1 d 20 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
moveToBill: fix loop reassigning order back to worse warehouse
- Break after first warehouse that covers remaining qty; loop used to
fall through and overwrite fulfilment WH with every subsequent snapshot,
so orders ended up pinned to the last (least-available) candidate.
- Sort candidates by net availability (availability - reserved) desc
so the best warehouse is tried first.
- Track remainingQty across splits; keep current orderId on the chunk
being placed and move the leftover to the deferred order.
- Null guard on itemSnapshots when no vendor under the billing WH has
stock/reservation for the item. |
|
| 36331 |
1 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/ |
Fix @Cacheable name collision between getSaholicStockList variants
SaholicInventoryServiceImpl:271 and :282 both used @Cacheable(value =
'saholicCISList') on no-arg methods. Spring's default SimpleKey.EMPTY means
both methods shared ONE cache entry — whichever was called first poisoned the
cache for the other, even though they return different filtered sets:
- getSaholicStockList (:272) runs selectWarehouseCisNew — tl.active=1 only
- getSaholicStockListWithoutCatalogMovingStatus (:283) runs
selectWarehouseCisNewWithoutCatalogMovingStatus — includes catalog moving
status join and filters out non-stocked OTHER/SLOWMOVING items
Renamed the second cache to 'saholicCISListWithStatus' so each method uses
its own namespace. Consumers of either method now get their method's actual
result, not a random earlier caller's.
This is a correctness fix (wrong cached data) more than a perf fix, though
it does mean both caches fill independently now (tiny cold-path DB uptick,
already mitigated by 5-min TTL via timeoutCacheManager). |
|
| 36330 |
1 d 22 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Fix getWarehousewiseCollection: add timestamp index, drop misleading FORCE INDEX
EXPLAIN on hadb1 showed the query was full-scanning transaction.userwallethistory
(1.9M rows) despite FORCE INDEX (idx_uwh_wallet_timestamp). The composite
(wallet_id, timestamp) needs an equality predicate on wallet_id to be usable,
but this query filters by uwh.timestamp at the scan level with no wallet_id —
driven from fofo_store via joins. Optimizer correctly rejected the hint and
picked ALL. Query averaged 773 ms across 4,095 calls (3,167 s cumulative).
- add_idx_uwh_timestamp_reftype.sql: new index on (timestamp, reference_type)
so the range scan narrows by time and reference_type filters inline.
- UserWalletRepositoryImpl:110: drop FORCE INDEX hint; let optimizer choose.
Updated comment to explain why.
Left PartnerCollectionPlanRepositoryImpl.getCommitmentCollectionSummary:117
untouched — that query drives from pcp → userwallet → userwallethistory and
the join has wallet_id = uw.id known at scan, so (wallet_id, timestamp) is
the right index there; FORCE INDEX remains appropriate. |
|
| 36329 |
1 d 22 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Tune rbmWeeklyBilling cache: 2m→5m TTL + sync=true
The RBM weekly billing aggregate query takes ~2s per call (1,924 cumulative hits
on hadb1 = 3,800s DB time). Previously cached for only 2 minutes with no
stampede protection — every 2m window, every concurrent dashboard load ran the
aggregate in parallel and burnt Hikari slots simultaneously.
- 2m → 5m: this is month-level aggregate bucketed by week, doesn't need
sub-minute freshness for an RBM dashboard.
- sync=true: single in-JVM computation per (monthStart, monthEnd) key per
expiry window; concurrent misses wait for the in-flight load instead of
racing to the DB.
fiveMintimeoutCacheManager already exists in CacheConfig:73 (Caffeine, in-memory,
so no Redis/LocalDateTime serialization concerns). |
|