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

Rev 37642 – Hot Deal brand: remove the 00:20 window-sync job and its ...

amit — Tue, 15 Sep 2026 17:39:34 +0530

amit – 1 file(s) modified
Hot Deal brand: remove the 00:20 window-sync job and its CLI flag - no date windows any more

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

Rev 37595 – Move the full partner-limit pass from every 20 minutes to ...

amit — Fri, 11 Sep 2026 19:24:56 +0530

amit – 1 file(s) modified
Move the full partner-limit pass from every 20 minutes to daily

The 2-minute sweep already recalculates the limit for every partner whose base
moved, which covers investment and utilisation - the inputs that actually change.
The full 980-partner rescan only exists for inputs base cannot see: credit risk,
the SIDBI floor and hard_limit.

Those move on a far slower clock. RISK_DECREASE_DAYS_THRESHOLD is 90 days, and
transaction.fofo_sidbi_sanction has had no new row since Oct 2024 and no recorded
settlement. Running the rescan 72 times a day to catch them was 71 wasted passes.

Folded into the existing daily job, after the aged-stock refresh so the limit pass
sees haircuts for partners whose Apple or demo stock crossed its threshold
overnight. Leaves two scheduled jobs instead of three.

Limit latency is unaffected - that is the 2-minute sweep's job and it is unchanged
(~3 partners per window show a changed base, peak 18). The --updatePartnerLimitWithBatch
CLI entrypoint is untouched for manual runs.

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

Rev 37589 – Drive credit limits off the investment sweep; stop phantom limit ...

amit — Fri, 11 Sep 2026 17:30:03 +0530

amit – 3 file(s) modified
Drive credit limits off the investment sweep; stop phantom limit writes

Adds the 2-minute sweep schedule and points the limit recalculation at the
partners whose base_value actually moved, instead of rescanning all 980 every
20 minutes. Measured on production: 3 partners change per 2-minute window on
average, peak 18.

- ScheduledSkeleton: 2-min sweepPartnerInvestment, daily refreshAgedStockDaily
at 00:20; the 20-min full pass is kept as a backstop for inputs base does not
capture (risk, the SIDBI floor, hard_limit)
- BatchScheduledTasks.sweepPartnerInvestment: sweep, then limits for changed
bases only
- calculateChangedPartnerLimits(restrictTo) to support that
- scaleMoney(): round to paise before comparing and storing. The limit comes out
of a double multiply, so 65123.7400 round-tripped as 65123.740000000005 and
compareTo called it a change. 208 of 230 'changed' partners in one production
run differed by under half a paisa, rewriting sd_credit_requirement and
dtr.credit_account ~14,000 times a day for identical values and churning the
SIDBI mirror. Real changes were never below a rupee, so 2dp cannot suppress one.
- getFirstBillingDates: one grouped query instead of one per partner

Credit limits for 24 partners will rise on the first sweep after deploy - that is
the aged-Apple double-deduction correction landing (see r37588), not a defect.

NOTE: cron is a standalone Spring Boot jar; the new schedules only fire once it
is restarted with --spring.profiles.active=scheduled.

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

Rev 37565 – IMEI activation: 20s tick lanes for oppo/realme/vivo, idle once the ...

amit — Thu, 10 Sep 2026 03:00:55 +0530

amit – 7 file(s) modified
IMEI activation: 20s tick lanes for oppo/realme/vivo, idle once the day clears

Replaces the two once-a-day passes with chunk-per-tick lanes. Each tick takes one
chunk and returns; when a brand's pool comes back empty its turn is skipped, and
when everything is clear the ticks do nothing and stay silent until midnight.

- browser lane (StandAlone): one chunk of 25 for one brand every 20s, oppo and
realme by turns. Still exactly one ChromeDriver alive at a time.
- vivo lane: its own tick, chunk of 250. It must not share the browser lane --
0.24s an imei against oppo's 10.2s means it would need ~70 hours behind them
for work it does alone in 39 minutes.

The snapshot is gone; the pool query is the cursor. That is what makes a restart
cost one chunk instead of the day: the 12:03 restart on 09-Sep forfeited ~4,000
lookups and the whole afternoon, and last_finish had read -1 for three days.

The snapshot existed to stop the re-ask loop (realme, 29-Aug: 4,524 requests
against 1,004 distinct imeis). That is now closed at the source instead -- oppo,
realme and motorola stamp every imei they asked about, not just the ones that
produced a map entry, so a failed lookup rests until tomorrow rather than coming
back on the next tick. Motorola is fixed pre-emptively; nothing schedules it yet.

Also:
- secondary and tertiary are merged by turns rather than concatenated. Safe while
a pass walked to the end; without that guarantee oppo's 163 tertiary serials sat
behind 3,819 secondary ones and would only be reached on a day that cleared.
- vivo abandons a tick rather than the chunk when the captcha solver returns no
code -- one probe per 20s while it is down instead of 250, and no rows rested
over a transient outage.
- the funnel gauges move from a pass to a day. due is measured on the first tick
after midnight, the rest accumulate, and last_finish_epoch becomes a real
completion clock. Truncation is detected at the midnight rollover, which is the
case that never reaches an end-of-run at all.

This does not create capacity. At the 21s/imei measured on 09-Sep the pool still
needs ~35 hours and will not clear; it now rolls over visibly instead of silently.
The lever for that is DAYS=1.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/ImeiActivationGauges.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MotorolaImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/OppoImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/RealmeImeiActivationService.java
~ /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 37499 – sales target and achievement added cron and flags

ranu — Tue, 01 Sep 2026 16:09:28 +0530

ranu – 7 file(s) modified
sales target and achievement added cron and flags

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.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-dao/src/main/java/com/spice/profitmandi/dao/entity/inventory/SalesTargets.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesTargetsRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/SalesTargetsRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciLombardService.java

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 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 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 37395 – observability: retire the dead Nagios monitoring path, migrate balance signals ...

amit — Tue, 25 Aug 2026 20:24:34 +0530

amit – 6 file(s) modified
observability: retire the dead Nagios monitoring path, migrate balance signals to Micrometer

There is no Nagios server and the NRPE daemons have been removed from every
host, so the properties files written under /var/log/services were being
produced for nobody.

Deleted:
- CronMetricsService: zero references. Spring instantiated the @Service so its
constructor registered three meters, but nothing ever incremented them --
cron_execution_* read 0 in prometheus while cron_job_count_total (from
CronJobMonitorAspect) had recorded 1,597 executions.
- NagiosMonitoringScheduledSkeleton.

Removed the nagios properties writes from ScheduledSkeleton (-155 lines) and
KnowlarityCallMonitorScheduler (-46, including its now-purposeless
markTaskComplete helper). These recorded a per-job 0/1 status that
CronJobMonitorAspect already captures properly as success, failure and
duration metrics.

Kept the two signals that are genuinely useful: SMS gateway balance and the
ThinkWalnut recharge wallet balance now publish as Micrometer gauges via the
new BalanceGauges component, scraped from /actuator/prometheus. -1 means 'not
read yet' so a scrape before the first run is distinguishable from a real zero.

No behaviour change to any scheduled job. Compiles clean.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/BalanceGauges.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/CronMetricsService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/NagiosMonitorTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/knowlarity/KnowlarityCallMonitorScheduler.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/NagiosMonitoringScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java

Rev 37292 – Hot deals: javadoc matches reindex-based sync syncHotDealFlags no longer ...

amit — Tue, 11 Aug 2026 15:59:29 +0530

amit – 2 file(s) modified
Hot deals: javadoc matches reindex-based sync

syncHotDealFlags no longer mirrors model_hot_deal into tag_listing.hot_deals;
since r37276 hot_deal_b is derived from the active window at index time, so the
daily job re-indexes models whose window opened today or closed yesterday.
Comment-only, no behaviour change.

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

Rev 37258 – Schedule syncHotDealFlags daily 00:20 (ScheduledSkeleton) + --syncHotDealFlags CLI arg: completes ...

amit — Thu, 06 Aug 2026 16:30:37 +0530

amit – 2 file(s) modified
Schedule syncHotDealFlags daily 00:20 (ScheduledSkeleton) + --syncHotDealFlags CLI arg: completes r37255 - without the skeleton trigger the tag_listing.hot_deals mirror never runs, so deal windows would not start/expire in Solr

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

Rev 37234 – Updated Gmail Timeout

vikas — Tue, 04 Aug 2026 19:21:13 +0530

vikas – 1 file(s) modified
Updated Gmail Timeout

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

Rev 37230 – Updated Gmail Timeout

vikas — Tue, 04 Aug 2026 18:49:00 +0530

vikas – 1 file(s) modified
Updated Gmail Timeout

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

Rev 37172 – PJP agenda instances: nightly 23:45 sync cron + manual run ...

amit — Thu, 30 Jul 2026 12:34:44 +0530

amit – 3 file(s) modified
PJP agenda instances: nightly 23:45 sync cron + manual run arg

Rev 37162 – Shopify Inventory Sync

vikas — Thu, 30 Jul 2026 10:57:40 +0530

vikas – 1 file(s) modified
Shopify Inventory Sync

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

Rev 37159 – Nightly partner identity integrity monitor (7 violation classes over fofo_store/user.user/user_accounts/user_role ...

amit — Wed, 29 Jul 2026 16:30:23 +0530

amit – 3 file(s) modified
Nightly partner identity integrity monitor (7 violation classes over fofo_store/user.user/user_accounts/user_role incl. same-GST/mobile multi-open-store mandate checks); scheduled 07:00 + CLI trigger partnerIdentityIntegrityMonitor

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

Rev 37083 – Wire noon price-drop cron to per-drop batch (PriceDropBatchService) @Scheduled("0 ...

amit — Tue, 14 Jul 2026 13:49:28 +0530

amit – 2 file(s) modified
Wire noon price-drop cron to per-drop batch (PriceDropBatchService)

@Scheduled("0 0 12") now delegates to
BatchScheduledTasks.reprocessPriceDropsWithBatch() -> PriceDropBatchService,
so each price drop commits in its own REQUIRES_NEW transaction instead of one
~20-min transaction holding user_wallet locks and timing out live
wallet/order/scan traffic at noon.

Requires profitmandi-dao PriceDropBatchService / PriceDropProcessingHelper.

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

Rev 37040 – on billing delay partner map to focus and revival

ranu — Thu, 09 Jul 2026 13:15:44 +0530

ranu – 3 file(s) modified
on billing delay partner map to focus and revival

Rev 36993 – Thread dryRun through sendCreditNote; --sendCreditNote defaults to dry-run (--live for ...

amit — Thu, 02 Jul 2026 13:15:44 +0530

amit – 3 file(s) modified
Thread dryRun through sendCreditNote; --sendCreditNote defaults to dry-run (--live for real); add 06:00-on-1st monthlyMarginsCnDryRun scheduled job

Rev 36552 – changeList

ranu — Fri, 15 May 2026 19:25:22 +0530

ranu – 1 file(s) modified
changeList

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

Rev 36511 – Add daily inventory snapshot reconciliation cron - syncs currentinventorysnapshot with ...

amit — Sun, 10 May 2026 16:20:47 +0530

amit – 3 file(s) modified
Add daily inventory snapshot reconciliation cron - syncs currentinventorysnapshot with scan truth for active tag_listing items - emails drift report via googleMailSender to sdtech - runs daily at 5:30 AM, CLI trigger: --reconcileInventorySnapshot

Rev 36361 – Switch @Scheduled updatePartnerLimit to batch-tracked version. Was calling legacy scheduledTasks.updatePartnerLimit ...

amit — Wed, 22 Apr 2026 19:39:16 +0530

amit – 1 file(s) modified
Switch @Scheduled updatePartnerLimit to batch-tracked version. Was calling legacy scheduledTasks.updatePartnerLimit (one synchronized tx, writes to all ~1500 partners each run, no audit). Now calls batchScheduledTasks.updatePartnerLimitWithBatch (writes only changed partners in per-partner REQUIRES_NEW, records each run in cron_batch / cron_batch_item, sends failure email on partial failures). Same cadence (every 20 min), same business logic. Runs are now visible in /admin/cron-batches UI.

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

Rev 36292 – Reduce DB scan pressure from runaway IMEI and IRN crons ...

amit — Fri, 17 Apr 2026 13:17:01 +0530

amit – 1 file(s) modified
Reduce DB scan pressure from runaway IMEI and IRN crons

- IRN cron (updateIrnsToInvoices): fixedDelay 2s -> 5s; migration cron
has finished but keeps full-scanning 821k orders every 2s for 0 rows
(every billed order already has irnGenerated populated true/false).
- IMEI activation crons: fixedDelay 60s -> 5min across all 6 methods
(vivoImeiActivation, vivoImeiActivationTertiary, oppo, oppoTertiary,
realme, realmeTertiary). Each was scanning orders since 2021-01-01
every minute; 5min is well within activation-latency tolerance.

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

Rev 36253 – Separate secondary/tertiary IMEI activation crons for Vivo/Oppo/Realme, perf fixes: shared ...

amit — Sun, 12 Apr 2026 10:26:19 +0530

amit – 8 file(s) modified
Separate secondary/tertiary IMEI activation crons for Vivo/Oppo/Realme, perf fixes: shared saveActivation, Response leak fixes, /tmp cleanup, OpenCV static init, early break, remove class-level @Transactional from StandAlone

~ /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/OppoImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/RealmeImeiActivationService.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 36113 – rbm rating consolidate mail

ranu — Tue, 31 Mar 2026 16:42:28 +0530

ranu – 2 file(s) modified
rbm rating consolidate mail

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

Rev 36065 – Fix:Mail error

aman — Wed, 25 Mar 2026 20:13:02 +0530

aman – 2 file(s) modified
Fix:Mail error

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

Rev 36058 – web socket done for agent status

ranu — Wed, 25 Mar 2026 17:17:34 +0530

ranu – 8 file(s) modified
web socket done for agent status

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/b2b/Listing.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/knowlarity/KnowlarityCallMonitorScheduler.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-cron/src/main/resources/META-INF/prod.properties
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlarityBreakLogService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlaritySocketTest.java

Rev 36003 – Fix:Delay report

aman — Tue, 17 Mar 2026 12:42:03 +0530

aman – 3 file(s) modified
Fix:Delay report

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

Rev 35980 – Removed cron optimized logic for smartdukaan

amit — Wed, 11 Mar 2026 14:19:07 +0530

amit – 4 file(s) modified
Removed cron optimized logic for smartdukaan

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/scratch/GiftRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/scratch/GiftRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/ScratchService.java

Rev 35788 – Schedule Shopify Product Sync

vikas — Wed, 18 Feb 2026 17:44:37 +0530

vikas – 7 file(s) modified
Schedule Shopify Product Sync

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.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-dao/src/main/java/com/spice/profitmandi/dao/service/shopify/InsurancePlanFetcher.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/shopify/ShopifyProductMapper.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/shopify/ShopifyProductSyncService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/shopify/ShopifySyncResultModel.java

Rev 35666 – Fetch PineLabs Offers Daily by Items

vikas — Fri, 06 Feb 2026 15:51:48 +0530

vikas – 2 file(s) modified
Fetch PineLabs Offers Daily by Items

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

Rev 35616 – Fixed delay to 5

amit — Wed, 28 Jan 2026 18:33:07 +0530

amit – 1 file(s) modified
Fixed delay to 5

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

Rev 35568 – Refactor ticket scheduled tasks: fix bugs, add test mode, improve ...

amit — Sat, 17 Jan 2026 12:06:59 +0530

amit – 4 file(s) modified
Refactor ticket scheduled tasks: fix bugs, add test mode, improve performance

Bug fixes:
- Remove break statement in alertforTicket that stopped after first user
- Remove duplicate ticketClosed() method (used 7 calendar days vs 8 working days)
- Update Application.java CLI handler to use refactored escalateTicket()

New features:
- Add email test mode: redirect all emails to tester via config
- ticket.email.testMode.enabled=true/false
- ticket.email.testMode.recipient=tester@email.com
- Add configurable auto-escalation: ticket.autoEscalation.enabled
- Working days calculation using WorkingDaysService (excludes Sun + holidays)

Performance improvements:
- Batch fetch ticketSubCategoryMap once per job, not per email
- All repository calls moved outside loops (N+1 query fix)

Escalation thresholds updated:
- L1 -> L2: 3 working days
- L2 -> L3: 3 working days
- L3 -> Final: 2 working days

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Rev 35522 – Added migration for 2 parties for gold

amit — Tue, 06 Jan 2026 16:51:59 +0530

amit – 1 file(s) modified
Added migration for 2 parties for gold

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

Rev 35326 – Fixed Schedule Tasks

amit — Wed, 26 Nov 2025 18:41:56 +0530

amit – 2 file(s) modified
Fixed Schedule Tasks

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

Rev 35178 – Added SD Credit Scheduler

amit — Sun, 12 Oct 2025 18:59:17 +0530

amit – 1 file(s) modified
Added SD Credit Scheduler

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

Rev 35177 – Added SD Credit Scheduler

amit — Sun, 12 Oct 2025 18:55:25 +0530

amit – 4 file(s) modified
Added SD Credit Scheduler

~ /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-dao/src/main/java/com/spice/profitmandi/service/transaction/scheduled
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/scheduled/SDCreditScheduler.java

Rev 35133 – due date cross added all active loan and change title ...

ranu — Mon, 06 Oct 2025 19:46:47 +0530

ranu – 1 file(s) modified
due date cross added all active loan and change title this mail

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