SmartDukaan – /

Rev 37486 – mail: fix prod outage -- MailOutboxService must not implement MailQueue ...

amit — Mon, 31 Aug 2026 18:32:25 +0530

amit – 2 file(s) modified
mail: fix prod outage -- MailOutboxService must not implement MailQueue

r37478 added 'implements MailQueue' to MailOutboxService. That took down both
ROOT.war and profitmandi-web.war on the 18:19 deploy today; every route 404'd
because neither Spring context would start.

MailOutboxService has @Transactional methods, so Spring has to proxy it, and
@EnableTransactionManagement in both WebDBContextConfigure classes runs with the
default proxyTargetClass=false. While the class implemented no interface Spring
proxied it with a CGLIB subclass, which is still a MailOutboxService. Adding an
interface switched it to a JDK proxy implementing only MailQueue, so all 39
sites that inject the concrete MailOutboxService failed:

BeanNotOfRequiredTypeException: Bean named 'mailOutboxService' is expected to
be of type MailOutboxService but was actually of type com.sun.proxy.$Proxy1519

The interface moves to a new MailQueueAdapter, which delegates to
MailOutboxService and carries no transactional annotations. MailQueueHolder and
EmailServiceImpl inject it by the MailQueue interface, so Utils.sendMail* and
EmailService still reach the outbox unchanged. MailOutboxService goes back to
implementing nothing, and its ~112 existing call sites are untouched.

Chose this over proxyTargetClass=true, which would have flipped proxying for
every interface-implementing service in the app -- too broad for a hot fix.

Verified with javap inside both built WARs: MailOutboxService declares no
interfaces, MailQueueAdapter implements MailQueue.

Note for cron: it shares the dao jar, so a rebuild picks this up. Do not restart
cron on trunk without rebuilding it first.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailQueueAdapter.java

Rev 37485 – carlcare: enable tecno alongside itel Itel went first because ...

amit — Mon, 31 Aug 2026 18:17:30 +0530

amit – 1 file(s) modified
carlcare: enable tecno alongside itel

Itel went first because it is the brand we can CHECK -- the DCR pull independently
produces itel dates to reconcile against, where tecno has no second source at all.
That check has passed:

- a 50-imei read-only trial answered 50/50, no errors, no sign rejections, and
agreed with our catalog brand on all 50
- 18 of the 50 carried a date, and every one of those 18 fell AFTER our own
billing date (3 to 1,111 days, median ~220)
- the first live tick after deploy returned the same rate: 16 dates, 32 not-yet-
activated, 1 malformed response absorbed by the has("status") guard

Tecno is also the reason this class exists. Itel was already served by the DCR pull;
tecno has been served by nothing since 2024-11-20 and has been manual CSV ever since.

Capacity: ~10,400 itel + ~1,890 tecno pending against 14,400 lookups a day. The
round-robin splits a tick four ways only while all four queues have work; tecno is
much the smaller pool, so it is exhausted a few hours in, its queues then come back
empty and itel gets the full 50 again for the rest of the day. Itel still clears
daily -- roughly 1,875 + 10,650 = 12,525 itel lookups against a 10,401 pool.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CarlcareImeiActivationService.java

Rev 37484 – cron metrics: register the status gauge as -1, not 0 ...

amit — Mon, 31 Aug 2026 18:17:00 +0530

amit – 1 file(s) modified
cron metrics: register the status gauge as -1, not 0

The gauge was created when a job STARTS, and 0 means failure, so any job still
running its first execution after a restart reported FAILED. Selenium-driven and
report jobs take minutes, so this is not a narrow window -- it put ten jobs on
the dashboard as failed after the 2026-08-31 restart when none had failed.

-1 means 'has not finished a run yet'. CronJobFailing matches == 0, so those
jobs are simply absent from the alert until they genuinely complete once.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/CronJobMonitorAspect.java

Rev 37483 – mail: migrate mail_outbox SENDGRID rows to RELAY (applied to production) ...

amit — Mon, 31 Aug 2026 18:11:23 +0530

amit – 2 file(s) modified
mail: migrate mail_outbox SENDGRID rows to RELAY (applied to production)

SENDGRID never meant SendGrid -- resolveSender() already routed it to the
Workspace relay, which is why outbox mail kept being delivered while direct
JavaMailSender injections failed against the real, dead SendGrid bean. So this
relabels rows without changing where anything is sent.

Applied to hadb1 2026-08-31 18:10 IST:
before SENDGRID=5956 RELAY=0 GOOGLE=4896 (total 10852)
after SENDGRID=0 RELAY=5956 GOOGLE=4896 (total 10852)
backup dtr.mail_outbox_sendgrid_backup_20260831_1810 (5956 rows)

The one PENDING row (id=26838) migrated cleanly and still routes to the relay.
Only GOOGLE and RELAY remain in the column. Rollback statement is in the script.

The comment claiming legacy SENDGRID rows exist is now false and has been
corrected; SendGrid appears nowhere in the codebase.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java
+ /trunk/profitmandi-dao/src/main/resources/sql/migration_mail_outbox_sendgrid_to_relay.sql

Rev 37482 – carlcare: recover tecno/itel activation dates, and fix trunk broken by ...

amit — Mon, 31 Aug 2026 17:59:36 +0530

amit – 4 file(s) modified
carlcare: recover tecno/itel activation dates, and fix trunk broken by r37479

r37479/r37480 swept a working-copy edit to Application.java into the mail commit: trunk
has called scheduledTasks.checkCarlcareImeiActivation() since then without containing it,
so profitmandi-cron has not compiled. This adds the rest.

WHAT THIS IS

The tecno feed has been dead since 2024-11-20, when transsion decommissioned the SAP
OData hosts cms.tecno-mobile.com:8099 / cms.itel-mobile.com:8099. The imwav DCR portal
recovers itel but has nothing for tecno -- all three tecno logins together expose 17
imeis over five years, against 31,928 tecno rows in fofo.activated_imei. Everything since
has been manual CSV via /imei/upload.

Carlcare is transsion's own after-sales arm, and the warranty-check page on carlcare.in is
backed by a public per-imei endpoint that answers for tecno, itel and infinix with no
login, no cookie and no captcha:

GET ind-mis-carl.shalltry.com/CarlcareClient/electronic-card/check-extended_warranty-web?imei=
sign: md5(SALT + imei)

The sign header is mandatory (without it: code 10022 "Sorry, web sign is error"). The salt
is in the site's own bundle, _nuxt/085537c.js module 688, along with the base url; re-read
that bundle if it ever stops working. status 3 = activated and carries activeTime, status
2 = device known but not activated yet and activeTime is null.

It is also the semantically right source. The DCR portal serves an INVENTORY report and
the old SAP feed served a TERTIARY SALES report, whereas activeTime is the date the
handset was actually activated -- which is what fofo.activated_imei is meant to hold and
what tertiary payout is computed on.

Measured against hadb1 before writing any of this: tecno 355463920708766 -> 2026-08-28 and
itel 359207322028000 -> 2026-08-30, both exact matches to rows we already had. A read-only
trial of 50 itel imeis answered 50/50 with no errors and no sign rejections, agreed with
our catalog brand on all 50, and returned a date for 18 -- every one of those 18 falling
AFTER our own billing date, 3 to 1,111 days, median ~220.

SHAPE

Pool queries and saveActivation semantics are the vivo ones, so the two read alike, and no
DAO change was needed: the pending queries are already brand-generic. The far end is far
cheaper than vivo's, one signed GET per imei, so there is no captcha service, no cookie
store, no session seeding and no verdict reporting.

50 imeis every 5 minutes = 14,400 lookups a day against ~10,400 pending itel, so the whole
pool is covered daily with headroom. The pool reaches back to 2021, so the ticks are
themselves the backfill of the nov-2024 blackout; there is no one-off to run.

Two things worth knowing before changing it:

- The batch is drawn ROUND-ROBIN across each (brand, channel) queue, not by concatenating
them. A full daily pass can concatenate freely because it walks to the end, but a
50-at-a-time tick cannot: itel is ~1,550 secondary against ~8,851 tertiary, so the head
of a concatenated list is ~31 straight ticks of pure secondary before one tertiary imei
is asked about. The first trial batch was 100% secondary for exactly that reason.

- Every outcome stamps the row, failures included. This is the one deliberate departure
from vivo, which leaves a failure unrecorded so it retries next pass -- safe there
because the next pass is tomorrow. On a 5-minute cadence it is not: an unstamped imei is
due again in five minutes, the query keeps handing back the same 50 rows, the batch never
advances past them, and the endpoint is asked the same questions twelve times an hour for
as long as it keeps failing. See the runaway documented on oppoRealmeImeiActivation.

BRANDS is itel alone to start. That is a rollout order, not a limit of the endpoint: itel
is the brand we can CHECK, because the DCR pull independently produces itel dates to
reconcile against, where tecno has nothing. Add "Tecno" once a day's rows agree. Both feeds
may write itel meanwhile with no coordination -- the pool query only returns imeis whose
activationTimestamp is still null, so whatever one fills has left the other's pool.

Scheduled tick plus a --checkCarlcareImeiActivation flag, both wired.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CarlcareImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java

Rev 37481 – imei activation: one 2-day billing floor for every brand, and ...

amit — Mon, 31 Aug 2026 17:59:05 +0530

amit – 3 file(s) modified
imei activation: one 2-day billing floor for every brand, and drop two dead methods

The pending pool is a UNION of two channels, not an intersection: an imei qualifies
if WE billed it to the partner (selectImeiActivationByBrand) or the PARTNER billed it
on to the end customer (selectImeiActivationByBrandTertiary). The two are disjoint by
construction -- the secondary query excludes anything carrying a FofoLineItem -- so a
unit moves from one to the other as it sells through and is never asked about twice.
Said so on the interface, since the pairing was only documented at the call sites.

billedBefore moves from now-1d to now-2d, so both channels ask only about stock billed
MORE THAN 2 DAYS ago. Anything sold in the last 48 hours has essentially never been
activated yet, so the lookup is spent for nothing; it is not lost, the same imei comes
back into the pool as soon as it crosses the floor, and again every day after that
until it activates. Kept in the repository rather than per caller so vivo, oppo, realme,
motorola and the new carlcare pass inherit one rule instead of drifting apart.

Costs almost nothing today -- secondary pool, old floor vs new:

itel 1550 -> 1550 realme 849 -> 849 oppo 2021 -> 2019
vivo 5018 -> 5016 motorola 1168 -> 1153 tecno 502 -> 495

26 rows across six brands, each deferred by one day.

Removed as dead:

selectImeiActivationPendingByRealme -- a verbatim duplicate of
selectImeiActivationPendingByBrand down to the named query and the parameters. Nothing
called it; StandAlone already used the brand-generic method for realme and said so in
a comment, which is now updated.

selectImeiSoldNotActivatedByBrand -- interface, impl and named query. No callers
anywhere in web, fofo, cron or dao.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ActivatedImei.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ActivatedImeiRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ActivatedImeiRepositoryImpl.java

Rev 37480 – mail: correct a wrong claim in r37479 -- the Google ...

amit — Mon, 31 Aug 2026 17:55:16 +0530

amit – 3 file(s) modified
mail: correct a wrong claim in r37479 -- the Google app password IS valid

r37479 stated googleMailSender's app password was rejected. That was wrong. The
test behind it resolved smtp.gmail.com over IPv6; repeating it over IPv4 with
the same credential gives AUTH OK on both 465 and 587.

The real fault is not the credential and not the bean config, both of which are
correct. SMTP from this host works over IPv4 only:

smtp.gmail.com IPv4 -> AUTH OK IPv6 -> 535 5.7.8 Username and Password not accepted
smtp-relay IPv4 -> 250 MAIL FROM IPv6 -> 550 5.7.1 Invalid credentials for relay

The JVM prefers IPv4, which is the only reason mail leaves this box at all.
Anything that prefers IPv6 fails on both paths.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37479 – mail: make the relay the default sender, not the Google ...

amit — Mon, 31 Aug 2026 17:49:38 +0530

amit – 3 file(s) modified
mail: make the relay the default sender, not the Google identity

Correcting r37474-37476. Those made googleMailSender @Primary on the assumption
its credentials worked. Tested against the live servers from the prod host:

googleMailSender 535 5.7.8 Username and Password not accepted (BadCredentials)
-- the app password in the source is no longer valid
relay over IPv4 250 OK for MAIL FROM:<noreply@smartdukaan.com>
relay over IPv6 550 5.7.1 Invalid credentials for relay

So promoting google would have replaced one broken default with another. The
relay is what actually delivers today and it becomes 'mailSender'. It does not
authenticate -- Workspace authorises it by allowlisted source IP -- so sending
as noreply@ is legitimate there and AuthenticatedIdentityMailSender correctly
leaves it alone.

googleMailSender stays available by qualifier. Point the default back at it once
a valid app password is issued for sdtech@smartdukaan.com.

Also noted in the javadoc: the relay allowlist covers the IPv4 address only, so
anything that prefers IPv6 will be refused.

Rev 37478 – mail: MailOutboxService implements MailQueue Adds the single entry point, ...

amit — Mon, 31 Aug 2026 17:38:59 +0530

amit – 1 file(s) modified
mail: MailOutboxService implements MailQueue

Adds the single entry point, queue(MailRequest). The twenty-odd queueMail*
overloads remain as delegates because ~112 call sites use them, but they now
funnel through one path rather than each building their own argument list.

Selecting the transport moves here too: MailSenderType.GOOGLE maps to the
authenticated sender, anything else to the relay.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java

Rev 37477 – mail: one way to send mail, and nothing sends inline ...

amit — Mon, 31 Aug 2026 17:38:48 +0530

amit – 8 file(s) modified
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.

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailQueue.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailQueueHolder.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailRequest.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/mail/MailSenderType.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/EmailService.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/EmailServiceImpl.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/Utils.java

Rev 37476 – mail: delete the dead SendGrid bean from fofo, make the ...

amit — Mon, 31 Aug 2026 17:19:03 +0530

amit – 1 file(s) modified
mail: delete the dead SendGrid bean from fofo, make the authenticated identity primary

googleMailSender is now @Primary and answers to 'mailSender'. Two senders remain:
the authenticated Workspace identity and the IP-authorised relay.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37475 – mail: delete the dead SendGrid bean from web, make the ...

amit — Mon, 31 Aug 2026 17:11:39 +0530

amit – 1 file(s) modified
mail: delete the dead SendGrid bean from web, make the authenticated identity primary

Removes the live SendGrid bean plus two commented-out corpses (an old
build@shop2020.in sender and a dead alias). googleMailSender is now @Primary and
answers to 'mailSender', so unqualified injections get the working authenticated
sender instead of one that rejects with 535.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37474 – mail: delete the dead SendGrid bean from cron, make the ...

amit — Mon, 31 Aug 2026 17:11:26 +0530

amit – 2 file(s) modified
mail: delete the dead SendGrid bean from cron, make the authenticated identity primary

The @Primary bean named 'mailSender' was SendGrid, so every unqualified
JavaMailSender injection got it -- and SendGrid rejects with 535, which is what
was failing 10 report/notification cron jobs (dailyTrackingReport,
monthlyTargetForPartner, sendFeebackSalesAndRbm and others). 420 occurrences in
one log.

googleMailSender now answers to both 'googleMailSender' and 'mailSender' and is
@Primary, so those injections resolve to a sender that works and whose From is
rewritten to the authenticated identity. No call site changes.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MailOutboxScheduler.java

Rev 37473 – mail: retire the SENDGRID sender label SendGrid was never ...

amit — Mon, 31 Aug 2026 17:11:25 +0530

amit – 1 file(s) modified
mail: retire the SENDGRID sender label

SendGrid was never actually used by the outbox -- resolveSender() already fell
through to the Workspace relay for it, which is why outbox mail kept working
while direct JavaMailSender injections failed.

Two senders remain, each named for what it is:
GOOGLE - authenticates as sdtech@smartdukaan.com; AuthenticatedIdentityMailSender
rewrites every From to that identity, because Workspace binds an
authenticated session to one address and rejects any other with
'535 Authorization failed: Authenticated user is not authorized to send mail'
RELAY - Workspace relay, no auth, authorised by source IP, may send as noreply@

Default convenience methods now route to RELAY explicitly rather than through a
label that named a provider we do not use.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java

Rev 37472 – IMEI activation: one snapshotted daily pass per brand, on one ...

amit — Mon, 31 Aug 2026 16:08:03 +0530

amit – 12 file(s) modified
IMEI activation: one snapshotted daily pass per brand, on one thread, with per-brand metrics

Four @Scheduled jobs every 5 minutes become two daily passes. Oppo and realme
share one thread and alternate in 25-imei chunks, so exactly one ChromeDriver is
alive at a time instead of four; vivo keeps its own thread since it is direct
HTTP and does not contend for a browser.

The pass snapshots its pool before any browser starts and walks that list to the
end. It never re-queries, and that is the actual fix. A failed lookup never
reaches dateMap.put, so no row is written, so createTimestamp is not bumped, so
the imei was eligible again on the next tick five minutes later. Measured 29-Aug:
realme issued 4,524 requests against 1,004 distinct imeis -- 4.5 asks each, 78%
of the day's budget spent re-asking -- while oppo, which rarely fails, sat at
1.03. More requests hardened the block, which caused more failures. A pass bounds
that: a failure costs one retry tomorrow, never one in five minutes.

This supersedes the r37447/r37448/r37449 argument about driver count, which was
about the wrong variable. That argument blamed realme's collapse on CPU
contention pushing the captcha render past the element waits. The logs do not
support it: on 29-Aug oppo took ZERO canvas timeouts across all 24 hours on the
same box, same six cores, same driver count, same captcha vendor, load average
0.9 -- including the 15:00-23:00 window in which realme solved nothing at all.
Realme's own canvas wait is 15s against oppo's 8s, so the longer wait is the one
expiring. What realme's timeout rate tracks is its own daily request volume, and
it resets at midnight: 920/day -> 0.3%, 3,467/day -> 28%, 4,524/day -> 75%. That
is realme.com declining to serve the widget.

DAYS=0 is deliberate and is not an off-by-one: the pool filter is
createTimestamp < now().atStartOfDay().minusDays(DAYS), so DAYS=1 measures
against yesterday midnight and silently yields a two-day cadence, which is what
oppo and realme were running.

Sizing measured on prod for a midnight start: oppo 4,133 and realme 2,118 imeis,
11.7h + 8.4h = 20.1 hours of a single thread. It fits with no slack; if the
'pass finished' counts come in short of 'pass starting', the lever is DAYS=1
rather than a second thread.

Observability: ImeiActivationGauges publishes the funnel per brand on
/actuator/prometheus, which alloy already scrapes on this host -- due, churned,
captcha_shown, captcha_solved, answered, dates_found, errors, run_seconds and
last_finish_epoch. Each stage fails differently and says what broke. Rates are
left to PromQL. The stage that matters for health is answered: churned>0 with
answered==0 is precisely the shape of both silent outages this year (oppo wrote
nothing for a week; the vivo captcha solver was dead for 46 days). dates_found is
deliberately NOT a health signal -- when the multi-year backlog drained at the
end of August, yield fell from ~100% to 2-3% on the same day across all three
brands with nothing broken.

Nagios cleanup: the Nagios server and every NRPE daemon are gone, so
WriteToPropertiesFile and the commented-out blocks that fed
nagios-cron.properties are deleted, and NagiosMonitorTasks is renamed
BalanceMonitorTasks for the transport it actually uses. Noted there that nothing
calls it -- there is no @Scheduled entry and no other caller -- which is why both
balance gauges have always read -1.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/BalanceGauges.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/BalanceMonitorTasks.java (copied from /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/NagiosMonitorTasks.java@37471)
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/ImeiActivationGauges.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/NagiosMonitorTasks.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/properties/WriteToPropertiesFile.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckOppoWarrantyTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckRealmeWarrantyTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java

Rev 37471 – IMEI activation pools: skip stock billed today or yesterday ...

amit — Mon, 31 Aug 2026 16:07:40 +0530

amit – 2 file(s) modified
IMEI activation pools: skip stock billed today or yesterday

Both pool named queries now exclude serials whose sale is inside the last 48
hours -- o.billingTimestamp for the secondary path, fo.createTimestamp for the
tertiary one. A handset sold in the last two days has essentially never been
activated yet, so the lookup is spent for nothing: measured on prod, the
sold-within-180-days cohort returns an activation date on 2.4% (vivo) to 8.4%
(oppo) of lookups, against 43-97% for stock sold over a year ago.

billedBefore is set in ActivatedImeiRepositoryImpl rather than passed by the
caller, so no method signature changes and every brand inherits it -- vivo,
oppo, realme and motorola all draw from these two queries and nothing outside
profitmandi-cron uses them.

This is correctness rather than capacity: it trims 30 imeis from the oppo pool
and 9 from realme.

Rev 37470 – Remove dead Itel/Tecno SAP activation services Both services call ...

amit — Mon, 31 Aug 2026 15:50:16 +0530

amit – 4 file(s) modified
Remove dead Itel/Tecno SAP activation services

Both services call SAP OData endpoints that Transsion decommissioned on 2024-11-20:

ItelImeiActivationService -> cms.itel-mobile.com:8099/.../ZTERTIARY_SALES_REPRT_SRV
TecnoImeiActivation -> cms.tecno-mobile.com:8099/.../ZTERTIARY_SALES_REPRT_SRV

Both hosts now refuse connections outright (verified from the prod app server).
That decommissioning is what stopped Itel and Tecno activation ingest within the
same hour on 2024-11-20; everything since has arrived via manual CSV upload.
Neither service has produced a row in 21 months and neither can again.

Removed:
- both service classes
- ScheduledTasks.checkItelImeiActivation / .checkTecnoImeiActivation, their
@Autowired fields and imports (the only callers)
- the --checkItelImeiActivation / --checkTecnoImeiActivation startup args

Unaffected: ItelImeiActivationNewService and checkItelImeiActivationNew, which
target the current imwav portal and were fixed in r37467.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/ItelImeiActivationService.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/TecnoImeiActivation.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java

Rev 37469 – rbm drr dashboard , all today po rbm view maped

ranu — Mon, 31 Aug 2026 13:40:26 +0530

ranu – 1 file(s) modified
rbm drr dashboard , all today po rbm view maped

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37468 – rbm drr dashboard new ui looks

ranu — Mon, 31 Aug 2026 13:14:17 +0530

ranu – 1 file(s) modified
rbm drr dashboard new ui looks

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37467 – Fix Itel/Tecno activation pull: live session tokens, correct credentials, per-account ...

amit — Mon, 31 Aug 2026 11:30:33 +0530

amit – 1 file(s) modified
Fix Itel/Tecno activation pull: live session tokens, correct credentials, per-account isolation

The imwav pull has never worked since it replaced the SAP feed. Three defects:

- Login response was discarded and the listing call sent p-auth/utoken values
captured by hand in Jul-2023, so every request went out with an expired session.
Now takes utoken/urToken from the login response.
- Itel (IN404338I) carried a stale password (Dukaan@1234), which is why its pull
started failing Feb-2026. Corrected, and the two missing Tecno branch accounts
(Noida IN411226T, Lucknow IN404339T) added - the code previously knew only
IN404338T, which has no enterprise scope and returns nothing.
- Existing rows were looked up by the activation date string instead of the IMEI.
serial_number is the primary key, so the lookup always missed and re-persisted a
row that already existed, colliding on duplicate key on any re-pull.

Also pulls each account independently so one dead login cannot abort the remaining
accounts, and fails loudly when the portal rejects a login or the report call
instead of proceeding into a confusing downstream error.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/ItelImeiActivationNewService.java

Rev 37466 – Show aged Apple stock on the partner Total Investment breakdown ...

amit — Mon, 31 Aug 2026 11:10:13 +0530

amit – 1 file(s) modified
Show aged Apple stock on the partner Total Investment breakdown

Adds an 'Apple Stock More Than 30 Days' row below 'Unbilled Activated Stock'
so the reason a partner's suggested credit limit dropped is visible. Display
only -- the figure is not deducted from the other rows.

Value comes from partnerStat.tmp, so it reads 0 until the cron that rebuilds
that file has run against the new build.

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/partner-investment.vm

Rev 37465 – Exclude aged Apple stock from investment when suggesting partner credit ...

amit — Mon, 31 Aug 2026 11:10:07 +0530

amit – 1 file(s) modified
Exclude aged Apple stock from investment when suggesting partner credit limits

Apple handsets a partner has held more than 30 days from GRN no longer count
toward the investment that drives the suggested limit. Applied in
getSuggestedAmount via getCreditableInvestment, covering the SDDIRECT,
hundred-percent and SIDBI branches. The aged amount is logged alongside each
limit change so a drop can be traced.

Scoped to the limit calculation only -- getTotalInvestment() is untouched, so
checkout payment options, the investment-OK gates and partner-facing screens
see the same stock value as before.

Measured on prod at time of commit: 580 units / ~3.94 Cr across 88 partners.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/PartnerLimitHelper.java

Rev 37464 – Track aged Apple stock on partner investment; add category filter ...

amit — Mon, 31 Aug 2026 11:10:00 +0530

amit – 5 file(s) modified
Track aged Apple stock on partner investment; add category filter to stock value lookup

selectPartnerStockValueMap now takes a nullable categoryId so the same query
serves both the existing Live Demo exclusion (null = all categories) and the
new Apple handset lookup (category 10006). Existing callers pass null and are
behaviourally unchanged.

PartnerDailyInvestment carries agedAppleStockAmount, populated in both the
single and batch investment paths. It is JPA-@Transient, so no schema change,
and it still travels through the partnerStat.tmp serialization the FOFO
investment screen reads. Deliberately not part of getTotalInvestment() -- the
deduction is a credit-limit policy, so stock value is unchanged for checkout,
the investment-OK gates and partner-facing screens.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerDailyInvestment.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentServiceImpl.java

Rev 37463 – Add aged-stock constants for Apple credit-limit haircut Apple handsets ...

amit — Mon, 31 Aug 2026 11:09:10 +0530

amit – 1 file(s) modified
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.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java

Rev 37462 – Fire TagListing Solr update after commit instead of inside the ...

amit — Mon, 31 Aug 2026 11:07:59 +0530

amit – 1 file(s) modified
Fire TagListing Solr update after commit instead of inside the write transaction

TagListingChangeListener used a plain @EventListener, so the async Solr rebuild
ran on a separate thread in a new transaction while the publishing controller
transaction was still open. FofoSolr.updateSingleCatalog then re-read
tag_listing on a connection that could not see the uncommitted rows and
re-indexed the pre-change price; for a catalog's first-ever listing it read
zero rows, took the isEmpty branch and deleted the doc from Solr.

Switched to @TransactionalEventListener(phase = AFTER_COMMIT). All publish
sites (TagListingController, PriceDropController, IndentController,
InventoryController, ModelHotDealServiceImpl) are inside a @Transactional
boundary, so no event is dropped.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/event/TagListingChangeListener.java

Rev 37461 – rbm drr dashboard new ui looks

ranu — Sat, 29 Aug 2026 16:19:05 +0530

ranu – 1 file(s) modified
rbm drr dashboard new ui looks

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/RbmBrandPartnerCountModel.java

Rev 37460 – rbm drr dashboard new ui looks

ranu — Sat, 29 Aug 2026 16:15:18 +0530

ranu – 4 file(s) modified
rbm drr dashboard new ui looks

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/RbmDrrDashboardController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37459 – Motorola IMEI activation: secondary + tertiary in one browser session ...

amit — Sat, 29 Aug 2026 14:31:10 +0530

amit – 4 file(s) modified
Motorola IMEI activation: secondary + tertiary in one browser session

Mirrors the oppo/realme combined jobs. MotorolaImeiActivationService drives
CheckMotorolaWarrantyTask, with MotorolaChallengeSolver for the challenge.

Cadence comes from the pool query, which defers an imei for `days` after each
attempt (saveActivation bumps createTimestamp even when no date came back), so
days=2 retries everything every two days. Pending pool measured 1,534
(1,182 secondary + 352 tertiary); at ~10-14s/imei, 60 per invocation is about
12 minutes of driver time and clearing the pool inside 48h needs roughly 26
invocations, i.e. an OS cron entry every 90 minutes.

Do NOT schedule it inside the oppo/realme window: each driver tree costs
~850MB and this box has been OOM-killed twice with tomcat the victim, so peak
concurrent drivers is the number that matters.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckMotorolaWarrantyTask.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MotorolaChallengeSolver.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MotorolaImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java

Rev 37458 – LOI payment screenshot: report upload failures instead of reporting the ...

aman — Sat, 29 Aug 2026 13:22:56 +0530

aman – 6 file(s) modified
LOI payment screenshot: report upload failures instead of reporting the field as missing

Submit validated the hidden #payment-sc-docId, but a file input keeps displaying the
chosen filename regardless of what happens next - so a failed /document-upload left the
field looking attached to the operator and missing to the validator ("The following
fields are required: Payment screenshot" on a form that was in fact filled in).

The failure was silent three ways: doAjaxUploadRequestHandler had no error handler; the
global ajaxError reporter calls bootbox, which loads from cdnjs and throws if that is
blocked; and the confirm('Confirm file upload ?') gate returned false with no trace once
Chrome's "prevent this page from creating additional dialogs" box was ticked.

- common.js: optional error callback on doAjaxUploadRequestHandler (additive, opts out of
the generic global dialog via suppressGlobalError); uploadErrorMessage() extracts the
server's real reason from the JSON body or the plain-text duplicate-request body;
uploadDocument() pre-checks size/type, verifies a document_id actually came back, and
reports a message naming the file - .HEIC and .webp get specific guidance;
showAlert() falls back to native alert when bootbox is absent.
- loi-form.js: drop the confirm() gate, 'input' -> 'change', and clear the file input
whenever the id does not land so the widget can never claim an unuploaded file. Status
line under the field (Uploading... / Attached: name / Not attached). Submit now
distinguishes not-picked, still-uploading and upload-failed. Same treatment for the
OnboardingDocumentTable and mk_brand-fee-collection-details uploads, and the brand-fee
dialog names the Attachment field instead of echoing the raw form key.
- loi-form.vm, pendingForm.vm: accept="..." on both file inputs plus the status span.
- FileUploadController: reject empty files, report actual size against the actual limit,
and resolveExtension() falls back to the filename when the browser sends a generic MIME
type (Android file managers send application/octet-stream for ordinary JPG/PNG/PDF).
- AppConfig: static resource version 395 -> 396 for the JS change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/FileUploadController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/common.js
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/loi-form.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/loi-form.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/pendingForm.vm

Rev 37457 – Lock the KYC state to the GSTIN on the LOI ...

amit — Sat, 29 Aug 2026 07:49:43 +0530

amit – 4 file(s) modified
Lock the KYC state to the GSTIN on the LOI

The LOI already captures and validates a GSTIN, and the first two characters of a
GSTIN are its GST state code - so once the LOI exists the KYC state is a fact
about that number, not something to re-type. When one is present the state
dropdown is prefilled from it and locked; otherwise it stays a normal
master-backed select.

Derived from the GSTIN rather than loi_form.gstState: that column is typed by
hand and holds values like 'UP', 'UTTAR PARDESH' and 'MADHAY PARDESH' which
resolve against nothing, and it is blank on 3 rows. Checked against prod - all
693 GSTINs on record are 15 characters and every one resolves through
statemaster.stateCode, and in all 14 rows where the two disagree the GSTIN is
right and the typed value is wrong or empty.

The lock is per row, not per page: the KYC screens list many onboardings, so the
derived state is passed as a map keyed by onboarding id. Blank rows carry their
onboarding id so a new KYC entry is locked too, which is the case that matters.

data-gst-locked keeps the row's dblclick edit toggle from re-enabling the field;
the value still submits because the JS reads it explicitly with .val().

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PartnerOnBoardingPanelController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/panel-listing.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/fofo-kyc-row.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/legal-kyc-row.vm

Rev 37456 – Block billing when NIC rejects the transporter GSTIN for e-way ...

amit — Sat, 29 Aug 2026 07:42:55 +0530

amit – 6 file(s) modified
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).

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/EwbTransporterFailureCache.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/GstProService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/integrations/gstpro/EwbTransporterFailureCacheTest.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/provider/ProviderController.java

Rev 37455 – Make the KYC state a master-backed dropdown instead of free ...

amit — Sat, 29 Aug 2026 07:31:14 +0530

amit – 5 file(s) modified
Make the KYC state a master-backed dropdown instead of free text

fofo-kyc-row.vm and legal-kyc-row.vm captured state as a free-text input, so
nothing stopped a spelling the master does not hold. That state is resolved back
through inventory.statemaster by name later, and an unresolvable one cannot be
turned into a state code. Both now render a $stateNames select, and all five
render paths in PartnerOnBoardingPanelController supply the list.

panel-listing.js reads these fields positionally, by td index and
input[type='text']. A select does not match that selector, so the value would
have come back undefined and KYC would have saved a blank state silently -
both selectors now target the select. Row editing is unaffected: the enable
toggle uses :input, which covers select.

Bump the asset version for the panel-listing.js change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PartnerOnBoardingPanelController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/panel-listing.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/fofo-kyc-row.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/legal-kyc-row.vm

Rev 37454 – Build googleMailSender as AuthenticatedIdentityMailSender The bean authenticates as sdtech@smartdukaan.com, ...

amit — Sat, 29 Aug 2026 07:24:40 +0530

amit – 1 file(s) modified
Build googleMailSender as AuthenticatedIdentityMailSender

The bean authenticates as sdtech@smartdukaan.com, so Google Workspace only permits
that address in From. Callers hardcode noreply@, which Gmail refuses with 535
'Authenticated user is not authorized to send mail', silently dropping every alert
sent through it. The sender now rewrites From to its own username at send time.

See profitmandi-common r37451.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37453 – Build googleMailSender as AuthenticatedIdentityMailSender The bean authenticates as sdtech@smartdukaan.com, ...

amit — Sat, 29 Aug 2026 07:24:39 +0530

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java

Rev 37452 – Fix e-invoice IRN failure when the NIC auth token is ...

amit — Sat, 29 Aug 2026 07:24:31 +0530

amit – 2 file(s) modified
Fix e-invoice IRN failure when the NIC auth token is about to expire

NIC reissues the same auth token until it genuinely expires, so evicting the cache
inside the 5 minute leeway hands back the identical near-dead token. getAuthenticatedHeaders
checked the leeway once, before that re-fetch, and never inspected what came back.
NSUPHR1770 filed with a token that had 12 seconds of life left and the gateway answered
412/GSP752 'eInvoice AuthToken not found or expired'; the invoice filed a minute later,
past the expiry and so on a genuinely new token, succeeded.

getUsableAuthToken re-checks the refetched token and, when it is still inside a 60s
floor, waits out the remainder before minting again. The wait is bounded by that floor
and every caller on this path is a cron/async thread already running against a 60s NIC
timeout with no transaction held open.

Also make the gateway's own failures legible. NIC rejections arrive as
{Status, ErrorDetails}, but failures the ASP raises in front of NIC use
{status_cd, error{error_cd, message}}, which shares no field name with RespPl: Gson
produced an all-null object and the stored reason degraded to the literal
'RespPl{Status=0, Data=null, ErrorDetails=null, InfoDtls=null}', indistinguishable from
NIC rejecting the document. RespGSPErr already modelled that envelope but was a
non-static inner class and so could not be instantiated by Gson; made it static and
copy the code and message into ErrorDetails, which every caller already reads.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/api/model/E_InvoiceCommon.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/GstProAuthService.java

Rev 37451 – Send authenticated mail as the account that actually authenticates ...

amit — Sat, 29 Aug 2026 07:24:19 +0530

amit – 1 file(s) modified
Send authenticated mail as the account that actually authenticates

googleMailSender logs in to smtp.gmail.com as sdtech@smartdukaan.com, but callers
build their From as noreply@smartdukaan.com. Google Workspace binds an authenticated
session to one identity and refuses the mismatch with 535 'Authorization failed:
Authenticated user is not authorized to send mail' - the password is accepted, the
message is not. Every alert routed through that sender was therefore lost at the SMTP
layer, the e-invoice failure alert for NSUPHR1770 among them.

AuthenticatedIdentityMailSender rewrites From to the sender's own username at send
time, keeping whatever display name the caller chose. Senders that do not authenticate
are left alone: gmailRelaySender is the IP-authorised relay and has no username, and
sendGridMailSender's username is the literal 'apikey', so both keep noreply@.

Enforced in the sender rather than at the ~40 call sites that build their own
MimeMessage and hardcode noreply@, so it covers the ones added next too.

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/AuthenticatedIdentityMailSender.java

Rev 37450 – Oppo: find only the hole, and let a low-contrast hole ...

amit — Sat, 29 Aug 2026 07:17:00 +0530

amit – 1 file(s) modified
Oppo: find only the hole, and let a low-contrast hole be found at all

60% of oppo attempts never got past detection -- getMatCircles2 returned null and
the attempt was wasted before any aiming happened. That is a bigger loss than
everything the scheduling work addressed put together.

Two causes, both visible once real puzzles are captured and looked at.

1. param1 is the Canny HIGH threshold, and it was 100. Edges weaker than that are
discarded before circle finding begins. Measured hole-vs-background contrast on
four live puzzles: 98, 103, 28, 117. The 28 -- a pale lilac background -- cannot
produce an edge at 100, so no circle exists to find. Dropped to 50.

2. It insisted on TWO circles whose radii matched within 3px, and returned null
otherwise. So a puzzle where the hole was located perfectly still failed if the
ring was missed, or if the two radii differed by 4px.

The second is the sillier one: the ring is a DOM element,
dx_captcha_basic_sub-slider_, whose exact position aim() already reads via
pieceCentreX(). Detection was re-finding something known exactly, and then
throwing away a good hole because it could not confirm it. Now the ring position
is passed in and hough only has to find one thing.

Lowering param1 without the pairing check would let textured backgrounds (the
sand images especially) supply spurious circles with nothing to reject them, so
the candidate is verified as an actual hole: its core must be at least 15
luminance below the frame mean. Real holes measure 28-117 below, so 15 rejects
noise with margin.

Validated against live puzzles before committing:
ring is at rel 42px on every sample; hole lands at 113-194px, separation
71-152px -- so RING_EXCLUSION_PX = 30 never rejects a real hole
hole contrast 28-117 against MIN_HOLE_DARKNESS = 15

Not validated locally: the hough call itself. opencv 3.4.2-0 ships no osx/arm64
native and every JDK on this machine is arm64, so the detection path cannot run
here. param1 = 50 is reasoned from the measured contrasts, not measured. If the
detection rate does not move, 40 is the next value to try -- the darkness check is
what makes going lower safe.

Watch "Detected N circle(s) but all sat on the ring" and "Rejecting circle at Npx"
in the log: the first means hough found nothing but the ring, the second means the
darkness check is doing its job.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckOppoWarrantyTask.java

Rev 37449 – Realme unmerged too: four selenium jobs, one per pool per ...

amit — Fri, 28 Aug 2026 20:25:12 +0530

amit – 1 file(s) modified
Realme unmerged too: four selenium jobs, one per pool per brand

r37447 merged secondary and tertiary per brand to halve concurrent drivers.
r37448 reverted that for oppo, because serialising cost it more per imei than a
second browser did. This reverts it for realme as well, which ends the merge
experiment entirely.

What the merge actually cost realme is only visible now that oppo is parallel
again: realme's per-imei went 14.2s -> 29s. It did not change behaviour -- it is
simply competing with oppo's two browsers for CPU. At 29s its merged ceiling is
86400/29 = 2,979/day, just under the 3,054/day the daily re-check needs, so no
batch size could have closed the gap. Two parallel pools restore the ~3,900/day
it managed historically at four drivers.

Measured before this change (25 min window):

brand needed/day throughput note
Oppo 8,838 7,661 parallel revert worked, +122%
Realme 3,054 1,843 merged and CPU-starved
Vivo 10,082 16,128 surplus, cannot transfer to another brand

Sizes unchanged: oppo 25 per pool, realme 12 per pool, vivo 50+10.

Honest accounting of the merge: it was my idea, sized on per-brand arithmetic that
ignored contention between brands, and it is now fully reverted. What survives
from that line of work is the part that actually paid -- reaping orphaned browsers
(~1.8GB), the per-brand retry caps, and per-brand maxResults. Peak drivers are
back to 4, which is where they started.

Watch for contention: four browsers is the configuration that produced the 29s
figure for realme in the first place, so oppo may slow from its current 19.7s.
Re-measure both before tuning sizes again.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java

Rev 37448 – Daily re-check for all brands; Oppo back to parallel pools ...

amit — Fri, 28 Aug 2026 12:08:39 +0530

amit – 3 file(s) modified
Daily re-check for all brands; Oppo back to parallel pools

Two changes.

1. Re-check window 4 days (secondary) and 2 days (tertiary) -> 1 day everywhere.
Daily demand becomes the full universe rather than a fraction of it:

Oppo 4,798 + 4,040 = 8,838/day
Vivo 9,407 + 675 = 10,082/day (doing 15,345 -- fine)
Realme 1,973 + 1,081 = 3,054/day

2. Oppo's two pools run in PARALLEL again, reverting the merge in r37447 for that
brand only. Realme stays merged.

The merge was a straight trade of throughput for memory and oppo could not
afford it. Measured over 32 minutes and again over an hour the next morning:
3,555 then 3,456/day against 5,280 before merging. Batch cadence settled at a
very regular ~15.5 min per cycle, so a 30-imei merged batch takes ~10.5 min =
~21s/imei, against the 10.2s it managed unmerged. At 21s the ceiling is
86400/21 = 4,114/day even with zero idle, so no batch size and no shorter
fixedDelay could have reached 8,838. Serialising simply costs more per imei
here than running two browsers does.

Realme keeps the merge: it needs 3,054/day and delivers 2,952 merged, so a
small size bump covers it without a second browser.

Sizes: oppo 25 per pool (2 jobs in parallel), realme 12+12 merged, vivo 50+10
unchanged. Vivo has already cleared its entire secondary backlog -- the pool
reads 0 and both lists come back empty -- which is what the batch of 50 was for.

Cost: oppo goes back to two concurrent drivers, so the fleet is 3 rather than 2,
roughly +700MB. Acceptable against the ~2GB freed today by reaping orphaned
browsers and capping retries, but it is the reason realme was left merged.

Sizes are a starting point, not a final answer: oppo's per-imei time differs
markedly between merged and parallel modes, so re-measure before tuning further.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java

Rev 37447 – Selenium: one browser per brand instead of one per pool ...

amit — Thu, 27 Aug 2026 20:36:36 +0530

amit – 2 file(s) modified
Selenium: one browser per brand instead of one per pool

Oppo and Realme each ran secondary and tertiary as separate @Scheduled jobs, so
each brand opened two ChromeDrivers at once and the fleet ran four. Each driver
tree costs roughly 850MB. This box co-hosts a 9.4GB tomcat with ~3GB available
and has been OOM-killed twice this month -- tomcat was the victim both times, so
peak concurrency is the thing that matters here.

Combined into one job per brand. Nothing downstream changes: the two pools differ
only in which named query fills them, and both already funnel into the same
updateActivationDate -> checkWarranty -> saveActivation path. They are disjoint by
construction (secondary excludes anything with a FofoLineItem, tertiary is
FofoLineItem-based); distinct() is insurance, not a fix for a known overlap.

Sizing matters, because merging SERIALISES work that used to run in parallel and
keeping the old batch sizes would quietly cost throughput. Measured post-cap at
10.2s/imei (oppo, down from 14.6 after r37445) and 14.2s/imei (realme), solving
M * 86400 / (300 + M*t):

oppo 2 parallel jobs x10 = 4,299/day -> merged 15+15 = 4,277/day (parity)
realme 2 parallel jobs x10 = 3,910/day -> merged 10+10 = 2,959/day (-24%)

Oppo is sized to hold parity because it is already short of its 4,798/day need.
Realme is left at 20 -- it needs 2,243/day, so it can absorb the dip in exchange
for shorter batches and a shorter-lived browser.

What this saves and does not save: total driver-SECONDS are roughly unchanged,
which is the point of resizing. PEAK concurrent drivers halves from 4 to 2.

Also skips starting a browser at all when both pools come back empty -- currently
never true, but it costs nothing and a browser launched to do nothing is pure
waste on this box.

checkOppoImeiStatus/Tertiary and the realme equivalents are left in place for
manual invocation; they are simply no longer scheduled.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java