| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37730 |
6 h 40 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/ |
Remove dead third-party integrations: common
Part of the integrations cleanup across all modules. Nothing here had a
live caller.
- Snapdeal product-page parser and UserMessagePojo (affiliate live pricing)
- FundFina request/response DTOs (inbound lender API, removed)
- Aramex XML tracking client (only reachable via /track provider=2)
- WiseApp insurance model
- URL constants for PayU, the SmartPing caller-ID hook, affiliate clicks and
live pricing; the SmartPing agent map |
|
| 37672 |
4 d 5 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/ |
Add BrowserLane: machine-wide interlock so only one headless Chrome runs at a time
Every ChromeDriver tree on the app box costs ~850MB RSS, on a host holding a
-Xmx8g tomcat and a -Xmx2g cron jar on 16GB that has been kernel-OOM-killed
twice with tomcat the victim. Peak concurrent drivers is the number that
matters, not drivers per day.
Measured on the oppo/realme lane: a 25-imei chunk takes 505s (12s driver
startup, then ~19.7s an imei) against a fixed 20s fixedDelay, i.e. a 96% duty
cycle. Meanwhile tomcat starts its own driver 8 times a day for the knowlarity
scrape. On 17-Sep that scrape ran 11:40:00-11:41:07 and the lane's next driver
came up at 11:42:21 -- it cleared by 74 seconds, by luck. At a 96% duty cycle
the collision cannot be dodged by choosing better times, only by serialising.
The two JVMs are separate processes owned by different users, so an in-process
flag cannot see across the boundary. Uses an OS file lock at
/var/lock/sd-browser.lock (overridable via -Dsd.browser.lock), created 0666 on
first use because cron runs as root and tomcat as tomcat and whichever starts
first creates it. A file lock rather than a marker file so the kernel reclaims
it when the holder dies: verified by SIGKILLing the holder mid-hold, the next
JVM acquired in 264ms. A ReentrantLock gates it first, since a second thread in
the same JVM would otherwise get OverlappingFileLockException rather than block.
Callers wait rather than skip. The knowlarity scrape needs 67s against a lane
busy 96% of the time, so skip-on-contention would mean it essentially never
refreshed again. Eight scrapes a day costs the imei lane about nine minutes of
waiting in total.
Fails open if the lock file is unusable (missing /var/lock, read-only mount, dev
laptop): serialising within the JVM only, rather than stopping imei activation
over what is a safety interlock. |
|
| 37668 |
4 d 22 h |
amit |
/trunk/profitmandi-common/src/main/ |
Validate GSTIN shape, state code and checksum
isValidGstNumber accepted any 15-character string, so a pincode (110095, rejected only for
length) and junk (Hdjiekwbdbsjskz) reached fofo_store.gst_number, which billing sends to NIC
as the recipient - the invoice is then refused and the goods cannot ship.
Now: 2-digit state code + PAN + entity + Z + mod-36 check digit, trimmed and upper-cased.
Blank still passes (the field is optional); callers needing one present check that themselves.
Checked against live data: 1,569 of 1,570 well-formed partner GSTINs pass, the one that fails
(HRSP330) has a genuinely wrong check digit.
Adds RTLR_1020 / RTLR_1021 for the invalid and mismatched cases. |
|
| 37665 |
5 d 0 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/solr/ |
Hot Deal brand: optional categoryId on the brand facet, so the chips can be scoped to one tab |
|
| 37661 |
5 d 1 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/ |
Fix trunk: RestClient was left behind by r37655
r37655 deleted MandiiResponse but omitted RestClient from the commit, so
trunk did not compile - RestClient still imported the deleted class.
RestClient now uses RawHttpResponse: executeMandii is renamed executeRaw and
postWithResponse returns the new type. The dead getMandii helper is removed;
its only caller was MandiiService. |
|
| 37655 |
5 d 1 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/ |
Remove the dead Mandii BNPL integration (common)
Mandii has taken no payment since 2022-08-23 and holds no credit account, so
MandiiService and the 29 classes only it used are deleted.
The package had become a home for live types, which are moved out rather than
lost: Gender/MaritalStatus/AddressProofType -> services.kyc (they back
@Enumerated columns on user.fofo_kyc, 317 rows), and the SD Credit account
status model - AccountStatusResponseOut and its 10 dependencies ->
services.sdcredit, still served by GatewayController for SDDIRECT.
MandiiResponse was a generic body+status holder named after the integration;
renamed RawHttpResponse, still used by RestClient for Kommuno recordings.
Its dead getMandii() helper is gone. AccountStatusResponseOut no longer
carries the hardcoded merchant.mandii.com URL it shipped to the app.
FundfinaService was logging under MandiiService.class - fixed. |
|
| 37638 |
6 d 1 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/ |
Hot Deal brand: HOT_DEAL_BRAND constant, oem_brand_s facet and hot-deal brand filter routing |
|
| 37627 |
6 d 5 h |
amit |
/trunk/profitmandi-common/src/ |
feat(mail): drop inactive recipients before send
Add MailRecipientFilter and RecipientFilteringMailSender, which strips To/Cc/Bcc addresses the filter reports inactive and skips a mail left with no recipients instead of failing. AuthenticatedIdentityMailSender now extends it. |
|
| 37619 |
7 d 2 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/solr/ |
Return active_b in the unlimited content search
The offer screen's model picker needs to mark delisted models as inactive when
it is asked to include them. The other unlimited-search callers read only
catalogId_i and title_s, so the extra field changes nothing for them. |
|
| 37514 |
20 d 0 h |
ranu |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/enumuration/ |
notification live |
|
| 37513 |
20 d 0 h |
ranu |
/trunk/ |
notification live |
|
| 37512 |
20 d 0 h |
ranu |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ |
notification live |
|
| 37511 |
20 d 0 h |
ranu |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/enumuration/ |
notification live |
|
| 37509 |
20 d 0 h |
ranu |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/enumuration/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37508 |
20 d 1 h |
ranu |
/trunk/ |
notification live new ....api and modification , ui |
|
| 37490 |
20 d 6 h |
amit |
/trunk/ |
errors: separate business, integration and bug -- three failures logged three ways
Everything was logged identically: ERROR, titled 'Internal Server Error', and in
web stack-traced twice (log4j2 plus printStackTrace, the second copy landing in
catalina.out). A partner mistyping an IMEI produced the same output as a
NullPointerException.
That makes the error stream unalertable. Measured over six hours across web and
fofo: 909 ERROR lines, of which 294 (32%) were ProfitMandiBusinessException --
HTTP 400s where the user is simply told what to fix. Any rule on ERROR rate
fires constantly, and an error tracker would rank 'insufficient balance' as the
top issue.
business WARN, no stack trace, 4xx -- expected, user-correctable
integration ERROR + dependency name -- ours is fine, theirs is not
anything else ERROR + stack trace, 500 -- a bug
New IntegrationException carries getDependency(), so two hundred failures of one
gateway group as one problem rather than two hundred unrelated traces. That
category did not exist: such failures were previously either a bare Exception
(indistinguishable from our own bug) or a business exception (which wrongly
blames the user).
printStackTrace removed from the web handler -- it was writing a second copy of
every trace to catalina.out.
Prerequisite for wiring the GlitchTip appender, which must not be attached until
ERROR means something. |
|
| 37489 |
20 d 23 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/ |
Restore Utils.html and Utils.htmlJson removed by r37477
r37477 reorganised Utils while consolidating the mail APIs and dropped its only two
instance methods. They have no Java callers -- they exist solely for Velocity, where
AppConfig binds new Utils() as $vmUtils -- so the compiler, IDE find-usages and any
grep over *.java all reported them dead.
With htmlJson gone, data-paramslist="$vmUtils.htmlJson(...)" stopped rendering usable
JSON on every report link (admin.vm:840, admin.vm:910, reports.vm:51). reports.js:7
then read $(this).data("paramslist") as undefined and returned true, letting the
browser follow the plain <a href> natively -- a GET against the @PostMapping
/reports/{projectName}/{fileName} (ReportsController:126), answered with GE_1007
"Request method 'GET' not supported". The modal POST path was the only way that
endpoint was ever reachable, so every partner report broke at once.
Confirmed against prod: zero occurrences in fofo.log for Aug 13/20/26/28/30, and 87
today starting 18:37:23, right after today's ROOT.war deploy. 13 distinct reports hit.
$vmUtils.html had two further callers that also come back:
offer_margin_detail_partner.vm:12 and :241 (offer description and notes).
Restored verbatim from r37476, and commented as template-only so the next refactor
does not read them as dead code again. |
|
| 37477 |
21 d 1 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/ |
mail: one way to send mail, and nothing sends inline
There were three overlapping APIs -- Utils.sendMail* (7 static overloads),
EmailServiceImpl.sendMail* (7 more) and MailOutboxService.queueMail* (20). The
first two built their own MimeMessage, hardcoded From: noreply@smartdukaan.com
in eleven places, and pushed straight down whichever JavaMailSender the caller
passed.
That From is why mail was refused: an authenticated Workspace session may send
only as the account it logged in as, and noreply@ is a different identity in the
same domain. Sending inline also meant a failed send was lost outright and took
the calling job down with it, which is how one expired credential came to mark
ten report jobs FAILED.
New in profitmandi-common:
MailQueue - the single entry point; queue() returns once the mail is
recorded, not once it is sent
MailRequest - one value object replacing the 34 overloads
MailSenderType - GOOGLE (authenticated, From rewritten) or RELAY (IP-authorised)
The interface lives in common while MailOutboxService implements it in dao,
because dao depends on common and not the reverse -- Utils and EmailService
could not otherwise reach the outbox at all.
Utils and EmailService keep their signatures so the ~38 call sites still
compile, but now delegate and ignore the JavaMailSender argument; choosing a
transport was never the caller's business. Both are marked deprecated.
MailQueueHolder bridges the static helpers to the bean and is documented as a
compromise, not a pattern. |
|
| 37463 |
21 d 8 h |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ |
Add aged-stock constants for Apple credit-limit haircut
Apple handsets held by a partner beyond AGED_STOCK_APPLE_DAYS (30) days
from GRN are excluded from the investment used to suggest a credit limit. |
|
| 37456 |
23 d 11 h |
amit |
/trunk/ |
Block billing when NIC rejects the transporter GSTIN for e-way bills
NIC files the e-way bill alongside the IRN, so a deregistered transporter
GSTIN returns Status=1 with InfoDtls[InfCd=EWBERR] (3029 "GSTIN - ... is
not active"): the IRN is valid while ewb_no stays null. Nothing downstream
reads that as a failure, so invoices kept being issued for goods that
could not legally move.
Cache the rejected transporter GSTIN in Redis and refuse to bill through
it. The block is keyed on the GSTIN, since one GSTIN is shared by several
warehouse_provider rows, and it carries the day it was raised so it lapses
at midnight and each new day re-tests NIC once. Correcting the GSTIN in
the provider panel lifts it immediately.
Only errors that are the transporter's fault block billing - NIC's 3029,
or any message naming the GSTIN we sent as TransId. Every other EWBERR
behaves as before: the IRN is filed and the e-way bill is retried later.
Guard sits in addBillingDetailsForGrouppedOrders before the pessimistic
lock and before any mutation, mirroring LogisticsServiceImpl#getEwbDetails
(order's own warehouse; self-pickup and runner skipped, as they travel on
a vehicle number rather than a transporter id). |
|