SmartDukaan – /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.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 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 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 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 37408 – Vivo IMEI activation: stop spending captchas on line items with ...

amit — Wed, 26 Aug 2026 12:38:10 +0530

amit – 2 file(s) modified
Vivo IMEI activation: stop spending captchas on line items with no IMEI

76% of production captcha rejections were line items whose serial number is
null. Vivo answers those with {"msg":"参数为空"} -- "parameter is empty" --
and status 0, which this code recorded as a captcha failure. So a correctly
solved captcha looked wrong, no activated_imei row was written, the line item
stayed pending, and it came back every 5 minutes indefinitely. Those rows were
permanently consuming roughly 43% of the run quota, which is why every tick ran
full at 20/20 and the backlog never drained.

It also made the model look far worse than it is: measured accept rate 44%,
while the same solver scores 85-93% when the IMEI is present. True captcha
accuracy is around 77%.

Fixed at source: both named queries now exclude null and blank serial numbers,
so such line items never enter the pool (this also covers the Realme caller).
The loop additionally skips them before fetching a captcha, so no captcha,
solver call or Vivo request is spent discovering it.

Found via the diagnostics added in r37407 -- the previous log line recorded
five words and discarded the response that named the cause.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ActivatedImei.java

Rev 37407 – Vivo IMEI activation: log why a captcha was rejected ...

amit — Wed, 26 Aug 2026 12:26:43 +0530

amit – 1 file(s) modified
Vivo IMEI activation: log why a captcha was rejected

Production refuses ~56% of submissions, but reading the stored images by hand
showed 9 of 10 carried the CORRECT code. Replicating the request from the same
box gives 85-93%, and every external difference was measured and ruled out:
real vs dummy imei (7/8 both), user-agent (83% both), session reuse (74 vs 75%),
two concurrent jobs (80% both), source IP, and fetch-to-submit delay from 0 to
10s (90-91% throughout). Vivo's reply is byte-identical in every failure, so the
payload carries no discriminator.

That leaves something inside this process, and the old log line recorded five
words and discarded the evidence. It now captures the code submitted, the imei,
the real fetch-to-submit latency, the session cookies actually held at submit
time, and Vivo's full response.

The cookies matter most: if the SESSION cookie is being dropped or rotated
between fetching the captcha and submitting it, the captcha would be validated
against the wrong session and refused despite a correct code -- which fits every
measurement above and is invisible from outside the JVM.

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

Rev 37402 – Vivo IMEI activation: report Vivo's captcha verdict back to the ...

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

amit – 2 file(s) modified
Vivo IMEI activation: report Vivo's captcha verdict back to the solver

Only this cron ever learns whether Vivo accepted a captcha (status 0 means it
was wrong), so it is the only place that can label the solver's training data.
After each checkCode response it now posts the image, the code and the outcome
to the solver's /verdict endpoint, which files the sample as accepted (the
prediction was right - a free label) or rejected (needs a human to label it).

The solver has been running at a measured 22.3% accept rate and no training
data was ever collected, so the model could not be improved at all.

Strictly best-effort: 2s connect / 3s read timeouts and every exception
swallowed. Data collection must never slow down or break IMEI activation.

The shared secret is read from CAPTCHA_VERDICT_TOKEN in the environment,
falling back to a captcha.verdict.token property, so it need not be committed.
Without a token the call is skipped entirely.

Also drops /tmp/captcha.jpg: the captcha bytes are needed in memory for the
verdict report anyway, so the two concurrently-scheduled Vivo jobs no longer
share one file and overwrite each other's image.

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

Rev 37393 – Vivo IMEI activation: validate captcha solver response before submitting to ...

amit — Tue, 25 Aug 2026 16:59:27 +0530

amit – 2 file(s) modified
Vivo IMEI activation: validate captcha solver response before submitting to Vivo

The captcha solver at 45.79.121.178 was down from 09-Jul-2026 to 25-Aug-2026
(uwsgi never restarted after a host reboot). nginx returned a 502 page for
every request. RestClient.executeJson returns the response body regardless of
HTTP status, so CaptchaService handed that HTML page to Vivo as the captcha
code and Vivo logged it as 'Found invalid captcha' - indistinguishable from an
ordinary wrong guess. The outage went unnoticed for 46 days.

CaptchaService now checks the response against the solver model's own 31-class
alphabet (^[1-9A-HK-NP-Z]{4}$) and returns null for anything else, logging the
offending payload. VivoImeiActivationService skips the IMEI when the code is
null instead of posting the garbage; it is retried on the next run.

Also drops a System.out.println of the full base64 captcha image.

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

Rev 36580 – Adjust IMEI activation deferral: secondary 4 days, tertiary 2 days ...

amit — Sun, 17 May 2026 15:36:54 +0530

amit – 2 file(s) modified
Adjust IMEI activation deferral: secondary 4 days, tertiary 2 days for Vivo/Oppo/Realme

~ /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 36420 – OkHttp→RestClient migration for IMEI activation services (Itel, Tecno, Vivo). Added ...

amit — Tue, 28 Apr 2026 18:18:07 +0530

amit – 8 file(s) modified
OkHttp→RestClient migration for IMEI activation services (Itel, Tecno, Vivo). Added test deps. Updated RunOnceTasks, ScheduledTasks, OrderTrackingService.

~ /trunk/profitmandi-cron/build.gradle
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/ItelImeiActivationNewService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/ItelImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/itelImeiActivation/TecnoImeiActivation.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ordertracking/OrderTrackingService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java

Rev 36260 – Fix: add @Transactional(NOT_SUPPORTED) on Vivo methods to suspend ScheduledTasks outer ...

amit — Mon, 13 Apr 2026 16:13:18 +0530

amit – 1 file(s) modified
Fix: add @Transactional(NOT_SUPPORTED) on Vivo methods to suspend ScheduledTasks outer transaction

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.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 33453 – Do not run Vivo Activations on 1st of every month

amit.gupta — Sat, 15 Jun 2024 15:09:29 +0530

amit.gupta – 1 file(s) modified
Do not run Vivo Activations on 1st of every month

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

Rev 31128 – Fixed Scheduling issues

amit.gupta — Fri, 04 Nov 2022 15:54:08 +0530

amit.gupta – 1 file(s) modified
Fixed Scheduling issues

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

Rev 30937 – Fixed activation logic

amit.gupta — Fri, 09 Sep 2022 16:00:29 +0530

amit.gupta – 4 file(s) modified
Fixed activation logic

~ /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 30430 – change

tejbeer — Wed, 18 May 2022 10:59:02 +0530

tejbeer – 4 file(s) modified
change

Rev 30376 – Added Einvoice Files

amit.gupta — Mon, 02 May 2022 21:06:30 +0530

amit.gupta – 1 file(s) modified
Added Einvoice Files

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

Rev 30371 – Added Einvoice Files

amit.gupta — Mon, 02 May 2022 18:01:52 +0530

amit.gupta – 1 file(s) modified
Added Einvoice Files

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

Rev 30369 – Added Einvoice Files

amit.gupta — Mon, 02 May 2022 17:32:59 +0530

amit.gupta – 1 file(s) modified
Added Einvoice Files

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

Rev 30343 – Added Einvoice Files

amit.gupta — Tue, 26 Apr 2022 17:53:58 +0530

amit.gupta – 1 file(s) modified
Added Einvoice Files

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

Rev 30337 – Fixed ahead issue

amit.gupta — Mon, 25 Apr 2022 17:55:17 +0530

amit.gupta – 1 file(s) modified
Fixed ahead issue

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

Rev 30335 – Fixed vivo

amit.gupta — Mon, 25 Apr 2022 17:41:27 +0530

amit.gupta – 4 file(s) modified
Fixed vivo

Rev 30329 –

amit.gupta — Fri, 22 Apr 2022 12:28:42 +0530

amit.gupta – 1 file(s) modified

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

Rev 30209 – Added Oppo Activation

amit.gupta — Sat, 26 Mar 2022 17:05:04 +0530

amit.gupta – 8 file(s) modified
Added Oppo Activation

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/StandAlone.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckOppoWarrantyTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/OnBoardingRelatedSchelduleTask.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/OppoImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java

Rev 29477 –

amit.gupta — Fri, 22 Oct 2021 16:16:17 +0530

amit.gupta – 1 file(s) modified

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

Rev 29471 –

amit.gupta — Wed, 20 Oct 2021 17:00:02 +0530

amit.gupta – 1 file(s) modified

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

Rev 29470 –

amit.gupta — Wed, 20 Oct 2021 16:59:41 +0530

amit.gupta – 1 file(s) modified

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

Rev 29469 –

amit.gupta — Wed, 20 Oct 2021 16:57:40 +0530

amit.gupta – 1 file(s) modified

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

Rev 29468 –

amit.gupta — Wed, 20 Oct 2021 16:31:21 +0530

amit.gupta – 1 file(s) modified

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

Rev 29466 –

amit.gupta — Wed, 20 Oct 2021 16:19:14 +0530

amit.gupta – 1 file(s) modified

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

Rev 29457 – commit

manish — Tue, 19 Oct 2021 20:03:19 +0530

manish – 2 file(s) modified
commit

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

Rev 29456 – commit

manish — Tue, 19 Oct 2021 19:25:01 +0530

manish – 1 file(s) modified
commit

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

Rev 29455 – commit

manish — Tue, 19 Oct 2021 19:20:25 +0530

manish – 1 file(s) modified
commit

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

Rev 29451 – commit

manish — Tue, 19 Oct 2021 19:11:50 +0530

manish – 3 file(s) modified
commit

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java