SmartDukaan – /

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

Rev 37446 – Per-brand batch sizes, and stop chrome forking a GPU process ...

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

amit – 6 file(s) modified
Per-brand batch sizes, and stop chrome forking a GPU process it cannot use

maxResults was hardcoded in the shared repository methods, so Oppo and Vivo were
forced to the same secondary batch (10) and all three to the same tertiary (10).
It is now a parameter, set per brand at the call site.

Sizing is arithmetic, from measured IN-BATCH per-imei time. Solving
M * 86400 / (300 + M*t) = needed/day:

brand needed/day t M required set to
Vivo 9,407 0.8s 36 50 clears, ~12,700/day
Realme 1,973 13.4s 10 10 was 5 = ~1,177/day, short
Oppo 4,798 14.6s 88 10 HELD, see below

Correcting an earlier measurement of mine: I reported Vivo at 13.6s per imei and
concluded its backlog could not be cleared. That averaged across the ~300s idle
gaps BETWEEN batches. In-batch it is 0.8s -- Vivo is 17x faster than I said, is
idle ~97% of the time, and 50 clears its pool comfortably. There is no wait in
the Vivo path; it is simply fast.

Oppo is deliberately NOT raised. At 14.6s it would need M=88, which means
20-minute batches and near-permanent chrome sessions. But that 14.6s predates the
retry cap (r37445), which cuts exhausted imeis from 20 attempts to 7 and should
drop it sharply. Re-measure before sizing Oppo, rather than guessing high on a
box with 3GB free.

Also: --disable-gpu, --disable-dev-shm-usage, --disable-software-rasterizer on
both selenium tasks. Headless needs no GPU yet chrome forks a gpu-process per
browser -- 6 were alive across the fleet, pure overhead. No behaviour change.

Batch size does not raise peak concurrency (fixedDelay means one batch per job at
a time, so never more than 4 drivers). It raises DUTY CYCLE, which converts
chrome's footprint from intermittent to sustained. That matters here: tomcat is
9.4GB, available is ~3GB, and the two OOM kills this month both took tomcat.

Cron-only deploy. The dao signature change has no callers outside cron.

~ /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/StandAlone.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.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 37445 – Oppo/Realme: cap captcha retries per tick at 7 and 12, ...

amit — Thu, 27 Aug 2026 18:47:45 +0530

amit – 2 file(s) modified
Oppo/Realme: cap captcha retries per tick at 7 and 12, measured per brand

Most captcha work goes to imeis that never succeed. Measured over the last
window: oppo 6,245 attempts for 308 successes, realme 13,842 for 399. The bulk
is imeis grinding all 20 attempts in one already-refused session and getting
nothing -- oppo 279 of them, realme 610.

The imei is NOT abandoned. A captcha failure is a technical failure, not an
answer, so it stays pending and the next tick retries it in ~5 minutes with a
fresh page and session -- which the data suggests beats continuing in a session
the widget has refused seven times. This caps grinding, not retrying.

Per-brand caps, because the distributions genuinely differ:

OPPO cap 7 97.7% of successes kept, 58.4% of work saved (3,648 attempts)
Pre-glide, 33% of oppo's successes came from attempts 8-20 and 20 was the
right number. Post-glide (r37440) that is 2%: the drag lands first or second
try. cap 5 keeps 95.5%/saves 67.7%, cap 10 keeps 99.0%/saves 44.8%.

REALME cap 12 96.0% kept, 35.7% saved (4,937 attempts)
NOT 7. Realme has no glide, so its successes still spread to attempt 10+ and
a cap of 7 would cost it 16.5%. It also burns more than twice oppo's work, so
the gentler cap still saves more in absolute terms.

Combined: 8,585 of 20,087 attempts saved, ~43% less browser work, for ~3% fewer
successes per tick -- and those imeis come back next tick anyway. Less Chrome
work matters on this box: it co-hosts a 9.4GB tomcat, has 3.5GB free and has been
OOM-killed twice this month.

The two caps are independent constants and must not be synced. If glide is ported
to realme, expect its curve to shift left as oppo's did and its cap can drop to
~7 -- but measure it, do not assume it.

Windows are ~2h (oppo's only ~30 min post-glide), so the right numbers may drift.
Worth re-reading the attempt histogram after a full day.

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

Rev 37444 – rbm drr dashboard new ui looks

ranu — Thu, 27 Aug 2026 17:36:31 +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 37443 – rbm drr dashboard new ui looks

ranu — Thu, 27 Aug 2026 17:33:30 +0530

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

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

Rev 37442 – rbm drr dashboard new ui looks

ranu — Thu, 27 Aug 2026 17:28:05 +0530

ranu – 5 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-today-arr.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/today_po_rbm.vm

Rev 37441 – bi access to gaurav mathur

ranu — Thu, 27 Aug 2026 17:02:33 +0530

ranu – 1 file(s) modified
bi access to gaurav mathur

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

Rev 37440 – Oppo: slide the drag in eased sub-moves instead of jumping ...

amit — Thu, 27 Aug 2026 13:27:35 +0530

amit – 1 file(s) modified
Oppo: slide the drag in eased sub-moves instead of jumping

Aim is solved and it did not finish the job: r37438 lands the ring 0-1px from the
hole on 103 of 104 drags and oppo still converts ~15%, with POSITION_MISMATCH on
the rest. So the widget is refusing drags that end in the right place.

Dingxiang scores trajectory and velocity as well as final position and returns the
same POSITION_MISMATCH for both, so our verdict cannot separate "wrong place" from
"wrong-looking movement". The circumstantial case for the latter:

oppo 0.91s hold, 2-3 discrete jumps -> 15%
realme 1.93s hold, slower and more -> 54-74%

and r37438 made oppo FASTER by removing the per-step screenshots, moving it further
from realme's profile rather than closer.

glide() traverses each leg as up to 18 small sub-moves on an ease-out curve
(1-(1-t)^2, quick then settling) with a 45ms pause between, so the pointer
describes a continuous decelerating path instead of teleporting.

Nothing about the DISTANCE changes -- it is still exactly what the derived ratio
says, and verified to land on it precisely: a 116px leg becomes
[16,15,13,13,11,10,9,8,6,6,4,3,1,1] and sums to 116. Negative legs work the same
way for overshoot correction.

To be explicit, since this is the thing not to get wrong: the ratio remains fully
derived. It starts at zero and comes only from measured movement, per attempt and
per step. Splitting a leg into sub-moves gives MORE measured legs, not fewer, so
the estimate sharpens rather than being replaced by an assumption. No constant is
introduced -- MAX_GLIDE_STEPS, GLIDE_PX_PER_STEP and GLIDE_PAUSE_MS describe the
path, not the relationship between mouse px and ring px.

Expected hold ~1.7s against realme's 1.93s. Oppo only.

This is a hypothesis test, not a known fix. POSITION_MISMATCH rate answers it in
one tick; if it does not move, drag dynamics is eliminated and the remaining
suspect is Hough picking the wrong circle pair on oppo's imagery, which needs
visual evidence rather than another code change.

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

Rev 37439 – Oppo: drop the stale nudgeFor javadoc that still referenced ASSUMED_RATIO ...

amit — Thu, 27 Aug 2026 13:12:09 +0530

amit – 1 file(s) modified
Oppo: drop the stale nudgeFor javadoc that still referenced ASSUMED_RATIO

Comment only, no code change.

nudgeFor() and ASSUMED_RATIO were removed in r37438, but the javadoc describing
them was left orphaned above ALIGNED_PX, still explaining how to size a probe from
an assumed px-per-px. That is precisely the thing not to reintroduce, and a stale
comment arguing for it is an invitation to do so.

Replaced with a note on why there is no assumed ratio: it is derived from real
movement on every attempt and re-derived on every step within it. The constant was
tuned twice (1.7 -> 0.67 -> 1.7) against measurements contaminated by the leaked
slider press, and never helped. The widget's px-per-px genuinely varies by
environment (1.4-1.5 in production, 1.1-1.2 locally) and by brand, which is the
reason it has to be measured rather than assumed.

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

Rev 37438 – Oppo: aim by tracking the ring element, not by re-detecting ...

amit — Thu, 27 Aug 2026 06:38:15 +0530

amit – 1 file(s) modified
Oppo: aim by tracking the ring element, not by re-detecting circles

r37437's closed loop could not close. Production, 13 minutes:

step 0 (probe) ok 36
lost the circles 32 (25 of them on step 1, right after the main move)
aligned within 2px 0

The probe worked and derived sane ratios (0.75-1.00), then the next measurement
returned null nearly every time and the loop bailed.

The cause is structural, not a tuning miss. getMatCircles2 needs Hough to resolve
TWO circles of similar radius, and as the ring closes on the hole they overlap and
stop being two. The measurement dies exactly at convergence, so no loop built on
"distance between two detected circles" can ever verify success. The old refine()
hit the same wall and silently released, which is why it never helped either.

So detection is now used ONCE, for what it is good at -- locating the hole while
the two are still far apart -- and from then on we track the ring's OWN element,
dx_captcha_basic_sub-slider_, whose rect stays readable however close it gets.

Validated on the live widget before committing:

bg element page x=556, width 288 CSS
ring centre page 598 -> 42 relative to bg
dark target 138 relative to bg -> page 694, gap 96px

The ring sits in the same 0-288 CSS space as OpenCV's x values, so bg.x + circleX
is directly comparable to the ring's position. That holds because getMatCircles2
crops by CSS coordinates and chrome runs --force-device-scale-factor=1. A 96px gap
matches the range production logs as "Distance is".

Also validated earlier that the ring's rect tracks a drag cleanly the whole way in
(+10 mouse -> +11 ring, repeatably), which is the property the circle detection
lacks.

The ratio is still derived per move and is now signed, so overshoot corrects itself
rather than needing to be detected. No screenshot or Hough pass per step either, so
the drag is quicker as well.

Oppo only. Realme is converting 78% and is not touched.

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

Rev 37437 – Oppo: derive the drag ratio from every move, and survive ...

amit — Thu, 27 Aug 2026 06:25:11 +0530

amit – 1 file(s) modified
Oppo: derive the drag ratio from every move, and survive a stale slider

Two changes, both oppo only. Realme is converting 82% and is left alone.

1. No assumed ratio -- aim() is a closed loop.

ASSUMED_RATIO only ever sized the FIRST probe, but the old path then derived
px-per-px once from that single probe and trusted it for the main move and the
correction alike. refine() re-measured the gap but reused the same ratio and
never checked whether its own correction landed, so one noisy probe poisoned
everything after it.

aim() seeds with a small fixed 12px nudge -- small enough that it cannot cross
the hole -- then re-derives the ratio from what each move actually achieved and
blends it with the running estimate. Up to 5 steps, stopping as soon as the gap
is within ALIGNED_PX.

It can also see overshoot, which a single pass cannot: the gap is |c1 - c2| and
cannot tell "not there yet" from "gone past", but if a move makes the gap GROW
we have crossed the hole, and the next step flips sign.

This removes the constant rather than retuning it, so it is immune to the scale
differences we measured between environments -- 1.1-1.2 px per px locally
against 0.67-0.86 in production. Supersedes r37433 and r37436 for oppo.
calibrate(), refine() and nudgeFor() are now dead and removed.

2. Re-find the slider when it goes stale instead of dropping the imei.

54 of 284 oppo presses (19%) died on StaleElementReferenceException, against 0
of 90 on realme -- the first asymmetry found between the two. Every one aborted
the attempt and forced a full page reload.

The logs place it exactly: "Margin Left before-" succeeds, then the catch fires,
so the handle goes stale between that read and moveToElement. It happens on
retry iterations (before- 4px, 1px), right after the doubleClick refresh swaps
the widget DOM -- the element found at the top of the attempt is already
detached by the time we act on it.

Now re-finds and retries once. The margin-left reads are also wrapped: they are
diagnostics and must never be the reason an attempt is abandoned.

Neither change is verified in production yet. The stale fix is the one with a
measured asymmetry behind it; aim() is a design fix for a mechanism that was
provably fragile, not a fix for a measured cause of oppo's 13%.

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

Rev 37436 – Oppo: back to ASSUMED_RATIO 1.7; 0.67 was fitted to contaminated ...

amit — Thu, 27 Aug 2026 06:20:52 +0530

amit – 1 file(s) modified
Oppo: back to ASSUMED_RATIO 1.7; 0.67 was fitted to contaminated data

r37433 set oppo to 0.67 on the strength of 3,694 production calibrations. It did
not help: 14% before, 13% after, across two independent windows.

Those 3,694 measurements were all taken while the slider press was leaking
between attempts (fixed in r37435), so 79% of them started from a corrupted
pointer state. The value was fitted to noise.

With that confound removed the clean comparison is realme: identical widget,
identical calibration code, ASSUMED_RATIO 1.7, converting 82% of drags against
oppo's 13%. Measured post-fix on comparable gaps:

Oppo 0.67 -> probe 52px, closes 37% of a 122px gap -> 13% success
Realme 1.7 -> probe 31px, closes 11% of a 105px gap -> 82% success

The smaller probe is the one that lands. A probe that eats a third of the gap
risks crossing the target during calibration, and the gap is measured as
|c1 - c2|, which cannot distinguish "not there yet" from "gone past" -- so the
derived ratio comes back wrong and the main move is wrong with it.

This converges on realme's value but is not a blind sync: it is the one
configuration observed to work on this widget once the press bug was gone. The
constants stay per-brand and independently documented.

Not a certainty. r37435 improved realme by 18 points and left oppo flat, so
something about oppo may still differ; this tests the cheapest remaining
explanation before going after circle detection.

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

Rev 37435 – Oppo/Realme: always release the slider; 79% of presses were left ...

amit — Thu, 27 Aug 2026 06:11:22 +0530

amit – 2 file(s) modified
Oppo/Realme: always release the slider; 79% of presses were left held

Found by following the observation that the dragger repositions itself on click.

clickAndHold() is issued at the top of every attempt, but release() sits inside
the moveByOffset > 0 branch. An attempt that fails circle detection, or produces
an unusable calibration, therefore leaves the mouse button DOWN.

Measured over 21 minutes of production:

Oppo 506 presses, 107 released -> 399 never released = 79%
Realme 247 presses, 58 released -> 189 never released = 77%

Actions is one instance per driver, created OUTSIDE the imei loop, so the stuck
press does not end with the attempt -- it leaks into the next attempt and on into
the next imei. The following clickAndHold then lands on an already-held button,
so the widget never repositions the handle and the drag simply continues from
wherever the pointer was abandoned.

That matches what the logs show. Validated locally against both live widgets:
a clean press repositions the handle +22px on the first pixel of movement (half
the 45px handle: moveToElement centres the pointer, the widget aligns to it), and
the transfer is then linear -- 1.10 piece px per mouse px on oppo, 1.20 on realme.
Production instead shows a jump of +0px on 31 oppo attempts and -34..-41px on
another 39, and oppo starts 13% of attempts with margin-left already >= 30px
(mean 9.2px) against realme's 0% (mean 3.2px). Those are the fingerprints of a
drag resuming rather than starting.

Tracks the press in a flag and releases on every exit: before the retry refresh,
and again after the loop so the widget-not-found break cannot carry a held button
into the next imei. Release is wrapped, so a failure to release is logged rather
than killing the batch.

Ruled out while getting here, so as not to re-chase: the reposition is NOT an
animation race (position is stable from t=0 to 1s despite transition:all), and it
is NOT asymmetric between the brands -- both snap +22px identically, so this bug
does not by itself explain oppo 14% vs realme 64%. Both brands should improve.

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

Rev 37434 – Oppo: capture the captcha verify separately from the puzzle refetch ...

amit — Thu, 27 Aug 2026 05:33:08 +0530

amit – 1 file(s) modified
Oppo: capture the captcha verify separately from the puzzle refetch

Diagnostic only, no behaviour change.

r37433's verdict logging shows all 58 captured oppo captcha responses are
/api/a (the puzzle fetch) and none are /api/v1 (the verify), while realme shows
/api/v1 on 20 of 25 failures. The tempting reading is that oppo's drag is never
submitted for verification at all.

That reading is not safe. __oppoCaptcha is last-captcha-call-wins, and the
widget refetches a puzzle immediately after a rejected verify. Oppo then waits
up to 5s for the error element before reading the signal -- ample time for the
refetch to overwrite the verdict. Realme reads off the lookup response instead,
which is why its verdict survives.

So "never verified" and "verified, rejected, then overwritten" both fit, and
they need opposite fixes: the first is a broken gesture, the second is aim.

Keeps the last /api/v1 body in its own variable plus a count, so the failure
line now reads verifies=N lastVerify=... and the two are distinguishable on the
next tick.

Ruled out already, so as not to re-chase: drag duration. Time held between
"Distance is" and "Move click performed" is oppo 1.4s mean / 2s max against
realme 1.6s / 3s -- effectively identical, so the widget is not abandoning
oppo's drag for slowness.

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

Rev 37433 – Oppo/Realme: split the slider tuning, and give Oppo its own ...

amit — Thu, 27 Aug 2026 03:19:34 +0530

amit – 2 file(s) modified
Oppo/Realme: split the slider tuning, and give Oppo its own failure verdict

The two classes drive the same dingxiang widget and have been edited in lockstep,
but they do not behave alike: measured over the last 11 hours as successes per
completed drag, oppo runs 11-17% and realme 60%. A change proven on one is not
evidence for the other, so the tuning constants are now documented as per-brand
and must not be synced.

Correcting the record while I am here: oppo has NOT regressed. Earlier "43%" and
"48%" figures were successes over FAILURES, and a small widget-verdict sample --
not successes over drags. On the consistent denominator oppo has been 12-15%
throughout, across r37422, r37424 and r37432 alike.

Oppo: ASSUMED_RATIO 1.7 -> 0.67.

It only sizes the calibration probe: nudge ~= gap / (2 * ratio), intended to
close half the gap. 1.7 came from one hand measurement. Production says
otherwise -- 3,694 oppo calibrations average 0.67 (realme 0.70 over 1,683), so
the probe has been closing about a fifth of the gap, not a half, and the ratio
is then derived from that needlessly small and noisy sample. Mean gap is 120px
for both, and 28% of oppo calibrations already overshoot.

Oppo: log the captcha widget's verdict on the failure branch.

Realme has carried this since r37428 and oppo never did, which is why realme's
failures name POSITION_MISMATCH and oppo's 85% say nothing. Without it there is
no way to tell a bad drag from a widget that never rendered.

Realme: comment only, no behaviour change. Its ratio is wrong in the same way,
but it is wrong while converting 60%, so oppo carries the corrected value first
and realme follows only if it helps.

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

Rev 37432 – Oppo: reinstall the capture hook after every navigation Oppo ...

amit — Thu, 27 Aug 2026 01:38:10 +0530

amit – 1 file(s) modified
Oppo: reinstall the capture hook after every navigation

Oppo installed the response hook after the first driver.get only. The other
three navigations -- the "field already filled" reset, the widget-not-found
reload, and the per-imei reset at the end of the loop -- did not.

Every navigation destroys the JS context, so __oppoCapInstalled, __oppoResp and
__oppoCaptcha are all wiped and never recreated. Oppo therefore runs blind from
the second imei of a batch onwards, permanently.

Live evidence from the 00:49-01:03 window after deploying r37431:

Success at attempt 12
Activation lookup for 1 <- the first imei, right after the initial get
No getDeviceInfo response 11
captcha said null on all 11

Both variables null on every miss is the signature: not a failed drag, an
absent hook. Realme does reinstall at all four of its navigations (r37423) and
in the same window captured 30 lookups from 30 successes, on the same box with
the same hook code -- so the hook itself is fine.

Deliberately not touching Oppo's success signal in this change. It still infers
success from the bar-inform error element being absent, which is the false
success pattern r37426 replaced for Realme, and it may well need the same
treatment. But the null hook explains the misses on its own, and changing both
at once would make the next measurement unattributable.

Not compile-verified: the local build was interrupted. The change is three calls
to an existing private method in the same class.

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

Rev 37431 – Realme/Oppo: capture the lookup off Response.prototype, not window.fetch Realme ...

amit — Thu, 27 Aug 2026 00:33:09 +0530

amit – 2 file(s) modified
Realme/Oppo: capture the lookup off Response.prototype, not window.fetch

Realme solves its captcha well -- the widget's own verify endpoint says
success:true on 526 of 829 attempts, 63% -- and records nothing. Every one of
those solved captchas is logged as "Failed" and the imei re-queued.

The lookup is not missing, it is invisible. realme's client calls Nuxt's $fetch
(ofetch), which takes its reference to globalThis.fetch when its bundle is
evaluated. That happens before driver.get() returns, so by the time
installResponseCapture wraps window.fetch the client is already holding the
original. r37425 added that wrapper and could never have worked.

Verified on the live page: the same $fetch request is invisible to a
window.fetch wrapper and visible to a Response.prototype one.

Response.prototype.json/.text are resolved per call, so patching them catches
any client whenever it took its fetch reference -- the same reason the
XMLHttpRequest.prototype.open patch has always worked (it is how the captcha
verdict gets captured today).

The clone is read with the ORIGINAL reader. Calling the patched one recurses
forever and hangs the page; that is not theoretical, it hung a test run.

Applied to Oppo as well. Its XHR path works today (673 lookups, 0 missed), so
this is defence against the same trap following any migration -- which is what
r37425 was reaching for and did not achieve.

Expected: Realme goes from 0 rows to roughly its captcha rate. Unchanged:
59% of attempts still never find the circles, same ceiling as Oppo.

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

Rev 37430 – Realme: widen the lookup match and report what the page ...

amit — Wed, 26 Aug 2026 20:19:02 +0530

amit – 1 file(s) modified
Realme: widen the lookup match and report what the page actually called

The captcha is being solved -- the widget returns success:true with a token --
but the lookup response is never captured, so awaitResponse times out and every
attempt records as failed. 19 'success' against 53 'failed' this hour with 0
lookups, while the widget's own verdicts are mostly success:true.

Matches on the customer-api host as well as the active/check path, in case the
endpoint moved with the page rebuild. A failed attempt now also logs the
non-captcha URLs the page did call, so if it is still missed the log names what
to match on rather than leaving it to guesswork.

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

Rev 37429 – Oppo: wait for the lookup response instead of reading it ...

amit — Wed, 26 Aug 2026 20:17:48 +0530

amit – 1 file(s) modified
Oppo: wait for the lookup response instead of reading it once

Oppo read window.__oppoResp immediately after the success signal, which races the
request that produces it: in the 20:00 hour 17 successes yielded 16 'no
getDeviceInfo response' and a single lookup, against 673 lookups and 0 misses
earlier in the day.

Now polls for up to 8s, matching Realme (r37426). A failed read also reports the
captcha widget's own verdict, so a miss says whether the drag was refused
(POSITION_MISMATCH) or passed and the lookup simply did not arrive.

Widget verdicts confirm the calibration work: 14 success:true against 18
POSITION_MISMATCH is 43% real aim accuracy, up from ~9% before r37422.

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

Rev 37428 – Oppo/Realme: record the captcha widget's own verdict alongside the lookup ...

amit — Wed, 26 Aug 2026 19:59:04 +0530

amit – 2 file(s) modified
Oppo/Realme: record the captcha widget's own verdict alongside the lookup

r37426 made the lookup response the success signal, which is authoritative but
silent about WHY a drag was refused -- a timeout looks identical whether the aim
was wrong, the widget never rendered, or the page changed again.

The captcha widget answers that itself: it calls captcha-ind-sec.heytapmobile.com
and its replies carry a status and message. The hook now keeps the last such
response, and a failed attempt logs it, so 'Failed = 3' becomes 'Failed = 3
(captcha said: ...)'.

Note what the widget does NOT give us: its init call returns the puzzle's y
coordinate but not the x, which is the secret being protected. So the circle
detection still has to find the horizontal target -- there is no shortcut there,
and that remains the largest loss (60% of Oppo attempts never find the circles).

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

Rev 37427 – src dashboard logic correction

ranu — Wed, 26 Aug 2026 19:45:06 +0530

ranu – 3 file(s) modified
src dashboard logic correction

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/AnalysisDashboardController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/DashboardController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/analysisDashboard.vm

Rev 37426 – Realme: treat the lookup response, not a missing error element, ...

amit — Wed, 26 Aug 2026 19:40:47 +0530

amit – 1 file(s) modified
Realme: treat the lookup response, not a missing error element, as success

After r37425 Realme logged 27 'Success at attempt' and 27 'no active/check
response captured' in the same window, and wrote 0 rows. The hook was not at
fault -- reproduced locally, it captures both XHR and fetch correctly.

Success was being inferred from the ABSENCE of dx_captcha_basic_bar-inform:

try { wait5Sec.until(visibilityOf(bar-inform)); log('Failed') }
catch { log('Success') }

realme rebuilt this page, so that element may no longer exist. The wait then
always times out and EVERY attempt reports success while the captcha was never
solved, no lookup fired and nothing was captured. The 27/27/0 is that exactly.

The response arriving is the only signal that actually proves the captcha
passed, so it now waits for that (polling, up to 8s) and treats its absence as a
failure worth retrying. This also removes the separate 'no response captured'
branch, since reaching the success path now means the response is in hand.

Oppo is left alone: its bar-inform detection is working (0 missed captures
against 673 lookups), so there is nothing to fix there.

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

Rev 37425 – Oppo/Realme: capture the response from fetch as well as XHR ...

amit — Wed, 26 Aug 2026 19:27:25 +0530

amit – 2 file(s) modified
Oppo/Realme: capture the response from fetch as well as XHR

r37423 got Realme solving the captcha again -- 4 of 4 on the first tick after
deploy -- but every one logged 'Result shown but no active/check response
captured'. The capture hook only wrapped XMLHttpRequest, and realme's page issues
the lookup through fetch, so it recorded nothing and each imei was stored with a
null date.

The hook now wraps window.fetch too, cloning the response before reading it so
the page still consumes its own body. Applied to Oppo as well: its XHR path is
working today, but the same silent failure would follow any move to fetch, and
the cost is a few lines.

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

Rev 37424 – Oppo/Realme slider captcha: size the calibration nudge from the gap ...

amit — Wed, 26 Aug 2026 19:05:20 +0530

amit – 2 file(s) modified
Oppo/Realme slider captcha: size the calibration nudge from the gap

r37422 replaced a 15px calibration nudge with a fixed 60px, which fixed the
under-measurement but introduced the opposite error. Production data over 764
calibrations shows 45% ended UNUSABLE (closed <= 0, i.e. the piece shot past the
hole and the measured gap grew instead of shrinking), and among gaps under 60px
it was 85%.

The nudge is now sized from the gap -- aim to close about half of it -- and
clamped to [10,60]. Replaying the real observed gap distribution: unusable and
overshoot fall from 21% to 2%.

The observed travel ratio in production is 1.13 circle px per slider px, against
1.68 measured locally; it varies with render scale, which is why the ratio is
still derived from the measurement. ASSUMED_RATIO only sizes the probe, and 1.7
errs toward a smaller nudge, which is the safe direction here.

Oppo is currently solving 43% (was 9% before r37422). Realme carries the same
widget and the same defect and has not been deployed yet.

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

Rev 37423 – Realme warranty check: retarget the rebuilt page and read its ...

amit — Wed, 26 Aug 2026 18:59:28 +0530

amit – 1 file(s) modified
Realme warranty check: retarget the rebuilt page and read its JSON

Realme has recorded nothing since 24-Aug, the same day Oppo stopped. Driving the
page confirms why: it was rebuilt and every selector the code used is gone.

.sn-input -> the field is now .imei-input input (placeholder 'Please input IMEI')
div.check-btn -> the submit is now an icon, .imei-input .search-icon

So it failed even earlier than Oppo did -- it could not type the imei, let alone
reach the captcha, which is why the log showed only 'Initiating webdriver...'.

The result now comes from the JSON the page already receives
(customer-api.realme.com/in/active/check) rather than an XPath keyed off a label
that no longer exists. That old locator also had an '| //h1[contains(@class,
title)]' branch which would silently match a page heading and try to parse it as
a date. The API is explicit: expiryDate (yyyy.MM.dd) and an isActivation flag,
so nothing is inferred from message text.

expiryDate is the WARRANTY EXPIRY, so a year is still subtracted -- warranty is
12 months as standard. Checked against our own records rather than assumed:
41,267 of 41,289 stored Realme activation dates precede the date we checked
them, averaging 13 days before, which is only consistent with the subtraction
already being correct.

Ports the r37422 captcha fix verbatim -- identical dingxiang slider, identical
15px calibration nudge that made it land ~30px out against a ~30px hole. And as
with Oppo the outcome is always recorded, even as null: findElement THREW when
the element was missing, so nothing was written and the imei was re-queued every
5 minutes indefinitely.

Also converts 29 System.out.println to the logger. The cron JVM's stdout is a
socket from the launching ssh session, so every diagnostic was going nowhere.

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

Rev 37422 – Oppo slider captcha: calibrate over a longer nudge and correct ...

amit — Wed, 26 Aug 2026 17:11:44 +0530

amit – 1 file(s) modified
Oppo slider captcha: calibrate over a longer nudge and correct before releasing

The captcha solves about 10 times in 115 attempts. The arithmetic was right; the
measurement feeding it was not.

To place the piece the code must first learn how far it travels per slider pixel,
which it did by nudging 15px and re-measuring. The piece moves ~1.7px per slider
px, so 15px closed the gap by only ~25px -- and Hough circle detection carries
about +/-2-3px per circle, so the ratio came from a measurement roughly 20%
wrong. That error was then multiplied across the whole remaining travel: on a
150px gap it landed ~30px out, against a hole ~30px wide.

Nudging 60px closes ~100px, so the same detection noise is ~5% rather than ~20%.
The code also released on its single computed offset, committing all of that
error to the final position; it now measures once more after the main move and
closes the remainder before releasing. Math.round replaces an (int) cast that
biased every move short by up to a pixel.

Monte Carlo over the measurement noise (20k trials, +/-8px tolerance): median
placement error 16.3px -> 2.1px, success 26% -> 98%. Holds across a 2x range of
travel ratios and degrades gracefully as detection worsens, because the ratio is
derived rather than assumed. Real-world will be lower -- the same model puts the
old code at 26% where production sees 9% -- so expect roughly 1 in 3, not 49 in
50, and read Success/Failed in the log to get the true figure.

The ratio is returned rather than held on a field: this is a singleton and the
Oppo secondary and tertiary jobs run through it concurrently.

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

Rev 37421 – EWB: recover existing e-way bill on NIC 604 instead of ...

amit — Wed, 26 Aug 2026 16:47:32 +0530

amit – 2 file(s) modified
EWB: recover existing e-way bill on NIC 604 instead of storing a placeholder

DCNSUPDL948 generated EWB 451765074092 at NIC, then the transaction rolled back and
the number was lost. Every retry hit 604 and stored the literal EXISTING-LOOKUP-NEEDED
with no validity date, which routed the PDF down the transporter branch and NPE'd on a
self-pickup dispatch with no warehouse_provider row. ~640 retries in 55 minutes, and
because the failure surfaced as an Error it escaped catch(Exception) and blocked six
other documents behind it.

- GstProService: on 604, look the bill up via GetEwayBillsByDate + docNo match and
return it in GENEWAYBILL shape; stamp NIC's generation time instead of now().
Throw when it cannot be recovered rather than persist a placeholder.
- InvoiceService: saveInvoiceInNewTransaction no longer propagates. It commits
irn_generated=0 with the reason so a failed document stops churning; already-filed
invoices being re-rendered are left untouched.
- InvoiceService: cron loop catches Throwable so one bad document cannot skip the batch.
- InvoiceService: null-guard warehouse_provider; omit the transporter line instead of
failing the PDF.
- recordIrnFailure: transport failures now park at 0 for escalation rather than
requeueing for unbounded retry.

~ /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/invoicing/InvoiceService.java

Rev 37420 – Oppo warranty check: read the JSON response instead of scraping ...

amit — Wed, 26 Aug 2026 16:23:17 +0530

amit – 1 file(s) modified
Oppo warranty check: read the JSON response instead of scraping the date

Oppo has recorded no activation dates since 23-Aug. With logging restored
(r37410) the cause is visible: the captcha IS solved -- 10 successes per tick --
and it then fails on the very next line with

no such element: //*[contains(text(),'UTC+5.5') or contains(text(),'Non-Activate')]

Their result is now label/value pairs, and the value is rendered from TWO text
nodes: dayjs(regDate).format('DD/MM/YYYY') plus a '(UTC+x)' suffix computed from
the browser's own timezone. XPath contains(text(),...) tests only the first node
-- the date -- so it never matched. 'Non-Activate' is gone too: an inactive
device now reads 'The system will update the date within 7 days of device
activation.' Verified against a replica of their DOM: old locator 0 matches, and
the value element yields '23/08/2026 (UTC+5.5)'.

Rather than chase their markup again, take the value from the source: the page
calls /oppo-api/basic/v1/getDeviceInfo and the response carries regDate as epoch
millis -- no date format, no locale, no timezone suffix to parse. A small hook
records that response as the page receives it; nothing extra is requested and no
captcha behaviour changes.

Also switches the outcome to always record the imei. findElement THREW when the
element was missing, which skipped the fallback entirely, so nothing was written
to dateMap and the row was re-queued on every run indefinitely -- 'Could not
capture date' appears 0 times in the log because it was unreachable.

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

Rev 37419 – Whatsapp botpenguin

vikas — Wed, 26 Aug 2026 14:03:37 +0530

vikas – 1 file(s) modified
Whatsapp botpenguin

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/RemarkScoreService.java

Rev 37418 – Whatsapp botpenguin

vikas — Wed, 26 Aug 2026 14:02:05 +0530

vikas – 3 file(s) modified
Whatsapp botpenguin

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/DuplicateRemarkDigestRunner.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/RemarkScoreRunner.java