Subversion Repositories SmartDukaan

Rev

Go to most recent revision | Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
37706 21 d 16 h amit /trunk/ cart: take the cart row before any line, to break a lock-ordering deadlock

InnoDB was rolling back cart edits with "Deadlock found when trying to get lock"
(GlitchTip #53, 27 deadlocks) and losing others to OptimisticLockException
"actual row count: 0; expected: 1" (11 issues, 42 events). Both are the same cause.

Two request paths took the same two rows in OPPOSITE orders. Adding a line INSERTs
into user.line, and line_cart_id_fk shared-locks the parent cart FIRST, line second.
Validation/hydration mutated the line rows FIRST and wrote cart.total_price second.
Run those concurrently on one cart and it is a cycle. Caught in the act on prod:

T1: INSERT user.line (cart_id=175180781) -> holds S on cart, waits S on line
T2: UPDATE user.cart SET total_price=269340.0, version=175 WHERE version=174
-> holds X on line, waits X on cart
*** WE ROLL BACK TRANSACTION (1)

Fix is to give every mutating path one order: cart, then lines. CartRepository gains
selectByIdForUpdate, and it is called as the first statement of each path that writes
a cart line. Re-taking it inside one request is a no-op.

A lock-ordering fix is all-or-nothing -- one path in the wrong order is enough to
re-form the cycle -- so this covers ALL TEN cart-line writers, not just the two that
happened to show up in the stack traces: createCartItem, clearCart, getCartValidation,
addItemsToCart (x2), addShoppingBag, validateForOpen (x2) and V2BillingController's
bind/unbindInsurance. The audit is worth re-running before adding another writer.

Note validateForOpen and getCartValidation WRITE despite their names (they correct
cart_line quantity/price and roll up cart.total_price), which is why a "validate" call
was ever holding write locks. The lock is placed accordingly; making those genuinely
read-only is a separate, larger change.

This also serialises concurrent edits to the SAME cart, which is what the @Version
column on Cart was already trying and failing to express. Different carts are
different rows, so there is no cost across partners.
 
37698 21 d 21 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ V2 getPricing: carry internal movement availability alongside the price

Mirrors the fofo change so the two /getPricing endpoints answer alike. V2 is dormant but
component-scanned, so it has to keep compiling against the service signature.
 
37681 22 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ feat(warehouse): resolve the logged-in user on V2 PO creation and GRN mismatch resolution

V2 mirror of r37680, keeping the dormant V2 controllers in step with the fofo MVC ones.

- createPurchaseOrder resolves the logged-in user via getEmailId + authRepository and sets createdBy
- resolvedMismatchRequest passes the resolver through

Pairs with r37679.
 
37676 22 d 5 h ranu /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ v2 version some fixes  
37666 23 d 1 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ Hot Deal brand: /fofo/hotDeals/brands accepts categoryId, so the brand chips match the active tab  
37657 23 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ Remove Mandii checkout, status and callback paths (r37655)

OrderController: the paymentOption MANDII branch and createMandiiOrder are
gone. GatewayController: the MANDII branch of payment/gateway/status is gone;
the SDDIRECT branch it sat in front of is untouched and still returns
AccountStatusResponseOut.

API endpoints removed, all of them Mandii-only:
- /cart/payment (CartController + its V2CartController delegate) existed
solely to poll Mandii for an order status and credit the wallet. It called
mandiiService unconditionally, so it already failed for any other gateway.
- /mandii, the payment-notification callback, a no-op logging stub in both
HdfcPaymentController and V2FofoHdfcPaymentController, and dropped from the
WebConfig auth whitelist in the fofo commit.

V2 twins touched only where they would otherwise keep a dead route alive or
fail to compile.
 
37649 23 d 10 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ Retire user.counter / user.privatedealuser write path (web)

createRetailer no longer creates a Counter, PrivateDealUser or address mapping; the
non-found branch keeps only the saholic-user address write it also did. Pairs with
dao r37648.
 
37641 24 d 2 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ Hot Deal brand: badge from brand, /fofo/hotDeals/brands facet, real availability on every listing, drop legacy hot-deals pause endpoints  
37635 24 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ feat(pricing): V2 log tag_listing price changes; reference TP instead of vendoritempricing in price drop and tag listing  
37633 24 d 3 h ranu /trunk/ preffered app version revert on server side it will be client side  
37632 24 d 6 h aman /trunk/ fix(loi): don't leave an LOI half signed when the signed PDF fails to save

Confirm Sign stores the partner OTP (/validateLoiOtp) before the browser builds and uploads the
signed PDF (/saveLoiDoc). When that second step failed - html2pdf not loaded from cdnjs, upload
rejected, tab closed, server error - nothing was shown, no LOI mail went out, no onboarding was
created, and because loiOtpPresent hid Generate LOI the filler could never re-sign (LOI 734).

- pendingFormList: loiOtpPresent only when OTP AND loiDoc are both saved; new loiSignIncomplete
flag shows a red "signed LOI not saved" note on the Pending LOI list (web + V2 app).
- loi-form.js Confirm Sign: every failure after the OTP says the LOI was NOT saved and how to
retry; checks html2pdf is loaded; success alert only after /saveLoiDoc confirms; no double submit.
- /saveLoiDoc (fofo + V2): refuses a document without a verified OTP; a repeat call for an
already saved LOI is a no-op (no second mail / completion).
- /validateLoiOtp (fofo + V2): clear message when no OTP was sent in 24h; reports the real
rejection reason (e.g. OTP already used) instead of always "wrong".
- sendSignedLoiPdfToPartner: filler without a manager no longer throws and rolls back the save.
- OtpProcessor.generateOtp: never hands back an already verified OTP under the 2-minute throttle.
- AppConfig version 423 for loi-form.js.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RhJD2sc6pf3Zd7f4hyGxhH
 
37629 24 d 7 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/ feat(mail): wire inactive-recipient filter and clean hardcoded addresses

Wire MailRecipientFilter into googleMailSender and gmailRelaySender. Remove inactive/unknown addresses from recipient and access lists, fix typo addresses, bulk uploader gate to akhil.kumar, V2 brand fee gate to kamini.sharma.
 
37624 25 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ feat(price-drop): auto-approve V2 price drop DP/MOP into external vendor catalog pricing  
37621 25 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ V2 /entity honours activeOnly, defaulting to false

Same defect as the fofo endpoint fixed in profitmandi-fofo r37620: the flag was
accepted and ignored. Defaulting to false keeps callers that omit it unchanged.
 
37605 27 d 3 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ Use the derived movement price in the v2 vendor controller too

Same change as the fofo controller: /getPricing returns the movement price for internal
suppliers, and addVendorPricingIfMissing is gone. This copy is component-scanned, so
leaving it behind would have kept writing the pricing rows the fofo side stopped writing.

Requires profitmandi-dao r37603.
 
37591 28 d 2 h amit /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ Route V2 admin wallet adjustment through WalletServiceImpl

Byte-identical duplicate of the fofo /walletUpdate handler, with the same missing
row lock. Points at the shared walletService.applyManualAdjustment so both
modules share one code path.
 
37548 30 d 8 h ranu /trunk/ v2 version some fixes  
37547 30 d 8 h ranu /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ v2 switch version fixes on server side  
37495 38 d 4 h amit /trunk/profitmandi-web/src/main/resources/META-INF/ Fix Pine Labs affordability prod config: drop placeholder pinelabs.api.* overrides

r36839 re-added pinelabs.api.base.url/client.id/client.secret to the web module with
REPLACE_WITH_* values, reintroducing the duplication removed in r35832. AppConfig loads
shared-prod first and the module file second, so these shadowed the real credentials and
every affordability call failed with UnknownHostException on plural.v2.pinepg.in
(NXDOMAIN) - 1,254 errors in one week. Removing them restores the working values from
shared-prod.properties (api.pluralpay.in).

pinelabs.account.* deliberately left in place: the web module pins merchant 11467 while
shared-prod has 356460, so removing those would switch the live payment merchant.
 
37491 38 d 8 h amit /trunk/ errors: ship ERROR events to GlitchTip via the log4j2 Sentry appender

io.sentry:sentry-log4j2:7.22.6 in all three deployables. Pinned to 7.x because
8.x drops Java 8; verified class major version 52.

minimumEventLevel=ERROR is load-bearing. It only became safe after r37490 moved
business validations to WARN -- 32% of the ERROR stream was HTTP 400s where the
user is simply told what to fix, and sending those would have made "insufficient
balance" the top issue and buried real bugs. Breadcrumbs come from INFO so an
issue arrives with the log lines that preceded it.

Attached to the application loggers only; framework noise is not our bug.

web's log4j2.xml is committed here. cron's and fofo's are held back: both carry
uncommitted local development paths (a user.home expansion, and an absolute
/Users path) that would break production logging and the Alloy log tailing.
Their Sentry blocks are staged locally and should land with whoever owns those
path edits.
 

Show All