| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 36349 |
14 d 2 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
V2 /offer/process/{offerId} now fire-and-forget via submitBatchAsync (dao r36347). Response adds a 'message' field alongside success=true so the UI can surface 'Offer N submitted for processing' or 'already being processed'. |
|
| 36348 |
14 d 2 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
/offer/process/{offerId} now fire-and-forget: calls offerBatchService.submitBatchAsync (dao r36347) and returns the status message immediately. User no longer waits on the 5+ min batch run; duplicate clicks for the same offer return 'already being processed' instead of spawning parallel deadlocking batches. |
|
| 36347 |
14 d 2 h |
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 |
14 d 3 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
rbm rating dashboard view commited |
|
| 36345 |
14 d 4 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
Route V2 /offer/process/{offerId} through OfferBatchService (dao r36342). Same motivation as fofo r36344: per-partner REQUIRES_NEW eliminates lock contention seen on offer 8802 and isolates failures. |
|
| 36344 |
14 d 4 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Route /offer/process/{offerId} through OfferBatchService (dao r36342). Per-partner REQUIRES_NEW replaces the single outer transaction — fixes lock-acquisition failures (e.g. offer 8802) by releasing row locks between partners and isolating per-partner failures in cron_batch_item instead of aborting the whole run. |
|
| 36343 |
14 d 4 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Delegate processOfferWithBatch to OfferBatchService (dao r36342). Removes the two private offer-processing privates now living in the shared orchestrator; drops unused OfferService/OfferProcessingHelper autowires. CLI entrypoint (--processOffersWithBatch) behavior unchanged. |
|
| 36342 |
14 d 4 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. |
|
| 36341 |
14 d 4 h |
aman |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Fix:Remove Fin-service team from wod request mail |
|
| 36340 |
14 d 4 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/ |
Narrow downloadInvoice: release JDBC before PDF streaming + clean error codes
OrderManagementController has class-level @Transactional(rollbackFor=Throwable),
so every downloadInvoice request held a Hikari connection for the entire HTTP
response duration — including the PDF streaming phase over a user's (often
slow) mobile network. The endpoint is the #1 JDBC-slot holder in production.
- Method-level @Transactional(propagation = NOT_SUPPORTED) suspends the
class-level tx for this endpoint so no connection is held by default.
- A short read-only TransactionTemplate scopes the single SELECT (order lookup
by invoice number) inside its own tx. Connection returns to the pool as soon
as the SELECT commits; file streaming then runs without any JDBC session.
- Bounds-check orders.isEmpty() — 2 IndexOutOfBoundsException per log window
previously, now a clean 404 with message body.
- Invoice-not-yet-generated stops surfacing as a 500 with stack trace
(1,534 occurrences in yesterday's log = #1 noise source). Now a 404 with
'please retry shortly' JSON body. Saves log disk and error-budget. |
|
| 36339 |
14 d 4 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/config/ |
Enable Hikari leak detection on cron pool (fofo/web already had it)
profitmandi-fofo and profitmandi-web DataSources already call
setLeakDetectionThreshold(30000); cron's DBConfig didn't. Aligning all three
so any future >30s connection hold in cron jobs logs the holder's stack —
matches the observability we already have on the web tier. |
|
| 36338 |
14 d 5 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Remove CronBatchService and OfferProcessingHelper (moved to profitmandi-dao r36337); update imports in BatchScheduledTasks and PartnerLimitHelper |
|
| 36337 |
14 d 5 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 |
14 d 5 h |
ranu |
/trunk/ |
sales dispostion updated |
|
| 36335 |
14 d 22 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
rbm rating dashboard view commited |
|
| 36334 |
14 d 22 h |
ranu |
/trunk/ |
rbm rating dashboard view commited |
|
| 36333 |
14 d 23 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 |
14 d 23 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 |
15 d 0 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 |
15 d 1 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. |
|