| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 36386 |
11 d 15 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ |
Revert r36385: drop DataIntegrityViolationException handler from profitmandi-web V1 and V2 global exception handlers. Default DB-error translation is kept only in the FOFO module for now. |
|
| 36385 |
11 d 15 h |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ |
Add DataIntegrityViolationException handler to V1 GlobalExceptionHandler and V2GlobalExceptionHandler. Translates MySQL truncation / duplicate / FK errors into HTTP 400 with a friendly message via the new DbErrorTranslator (V1 uses ResponseSender; V2 uses ApiResponse + ErrorDetail). |
|
| 36384 |
11 d 15 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
GlobalExceptionHandler: handle DataIntegrityViolationException via DbErrorTranslator so MySQL truncation / duplicate / FK errors surface as HTTP 400 with a friendly ProfitMandiBusinessException payload (rendered by common.js badRequestAlert). |
|
| 36383 |
11 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/exception/ |
Add DbErrorTranslator: translates Spring DataIntegrityViolationException (truncation / duplicate key / FK violation) into ProfitMandiBusinessException with prettified field label. |
|
| 36382 |
11 d 15 h |
amit |
/trunk/profitmandi-common/src/main/resources/ |
Add DB_TRUNCATION / DB_DUPLICATE / DB_FK_VIOLATION / DB_CONSTRAINT response codes for the new DataIntegrityViolationException auto-translator. |
|
| 36381 |
11 d 16 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
Dashboard API |
|
| 36380 |
11 d 16 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/response/ |
Dashboard API |
|
| 36379 |
11 d 16 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/response/ |
Dashboard API |
|
| 36378 |
11 d 16 h |
ranu |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/ |
code commit for reports section v2 |
|
| 36377 |
11 d 16 h |
vikas |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ |
Dashboard API |
|
| 36376 |
11 d 17 h |
aman |
/trunk/ |
Feat:Cart Api Implementation |
|
| 36375 |
11 d 18 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
Added Rising Star/NEW |
|
| 36374 |
11 d 18 h |
ranu |
/trunk/ |
schemes and offer for v2 version |
|
| 36373 |
11 d 21 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
login talktime hours cap on 100% |
|
| 36372 |
11 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Wallet: SELECT FOR UPDATE on user_wallet mutations to close lost-update hole
addAmountToWallet/consumeAmountFromWallet(x2)/rollbackAmountFromWallet all
follow a read-modify-write pattern on user_wallet with no pessimistic lock
and no @Version, so two concurrent tx for the same partner both read the
same pre-snapshot amount, compute their own deltas, and commit - the second
UPDATE silently overwrites the first's credit/debit. user_wallet_history
still gets both rows, so balance drifts vs sum(history) with no exception.
Replaces the misnamed (and body-broken) selectByIdForUpdate - whose
implementation was a plain selectById, not a lock - with a new
selectByRetailerIdForUpdate that issues SELECT ... FOR UPDATE via
LockModeType.PESSIMISTIC_WRITE, mirroring the idiom already used in
GenericRepositoryImpl.selectByIdForUpdate and OrderRepositoryImpl.
Preserves the create-on-missing behavior of selectByRetailerId so
first-time partners keep working.
Switches the four read-modify-write call sites in WalletServiceImpl from
selectByRetailerId to the new locking variant. Read-only callers
(getUserWalletByUserId, getUserWalletHistoryByUserId, etc.) keep using
the non-locking selectByRetailerId - MVCC snapshot reads stay non-blocking
for display/statement endpoints.
Also drops the stale commented-out selectByIdForUpdate line in
rollbackAmountFromWallet and removes the broken method from the
UserWalletRepository interface / impl - it had zero live callers.
Blast radius: every write call to these three wallet methods now holds
an X-lock on the target user_wallet row for the rest of the outer tx.
Concurrent write tx for the same partner will briefly serialize at the
SELECT FOR UPDATE - correct serialization instead of silent drift.
Read-only traffic is unaffected (MVCC). |
|
| 36371 |
11 d 21 h |
amit |
/trunk/ |
HDFC webhook: INSERT IGNORE on hdfc_payment to fix concurrent-duplicate 500 storm
Replaces persist() with a native INSERT IGNORE so concurrent same-UTR webhook
retries serialize on the unique-index check, and the loser gets a 0-row no-op
(warning, not exception). Outer @Transactional session stays clean, Spring
commits normally, HDFC sees 200 on both the winner (Success) and the loser
(Duplicate) - retry amplification ends.
Flow:
persist(hdfcPayment) -> insertIgnore(hdfcPayment) + selectByUtrNo(utr)
- inserted == 1: proceed with wallet / sidbi side-effects using fetched id
- inserted == 0: respond Duplicate, skip side-effects (owned by winning tx)
- defensive: log warn if insertIgnore returned 0 but selectByUtrNo finds
no row (could mean IGNORE swallowed a non-duplicate issue like truncation)
Also drops HdfcProcessingHelper (r36366) which used REQUIRES_NEW for the same
goal; that approach required a second JDBC connection and is no longer needed
with SQL-level idempotency.
Does NOT touch the wallet-side lost-update hole (user_wallet read-modify-write
without FOR UPDATE). That is a separate commit. |
|
| 36370 |
12 d 10 h |
vikas |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Fix: App login |
|
| 36369 |
12 d 14 h |
vikas |
/trunk/profitmandi-fofo/src/main/ |
Fix: Sale purchase invoice item quantity calculation |
|
| 36368 |
12 d 15 h |
aman |
/trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ |
Fix:Update Timeline Title |
|
| 36367 |
12 d 16 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/hdfc/ |
HDFC webhook: delegate writes to HdfcProcessingHelper; always respond OK
Fixes the concurrent-duplicate deadlock observed on hadb1 2026-04-23 12:54:11
(two HDFC retries inserting same utr='308490624083' → InnoDB deadlock →
LockAcquisitionException → 500 → HDFC retries again → amplification).
- addPayment: the HDFC row build + persist + wallet/sidbi is now a single call
to hdfcProcessingHelper.processPayment() which runs in REQUIRES_NEW. The
helper catches DataIntegrityViolationException and logs silently; our tx
is unaffected.
- The else branch (pre-select found an existing row) now returns the same
code=100 status=Success as the main path instead of code=200 Duplicate.
Per product direction: HDFC should see 'OK' regardless of whether the row
already existed from a prior webhook, manual entry, or reconciliation —
retries stop cleanly, no 'Duplicate' surface distinction.
Did NOT add @Transactional(readOnly=true) on the outer method despite its
read-heavy shape — checkManualPayments() at line 277 has a write side-effect
(rejecting pending manual wallet requests for the same utr) which would be
silently dropped in a read-only session. Kept class-level writable tx for
the outer; only HDFC writes moved to REQUIRES_NEW helper. |
|