| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37482 |
1 h 1 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
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. |
|
| 37472 |
2 h 53 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
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. |
|
| 37470 |
3 h 11 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Remove dead Itel/Tecno SAP activation services
Both services call SAP OData endpoints that Transsion decommissioned on 2024-11-20:
ItelImeiActivationService -> cms.itel-mobile.com:8099/.../ZTERTIARY_SALES_REPRT_SRV
TecnoImeiActivation -> cms.tecno-mobile.com:8099/.../ZTERTIARY_SALES_REPRT_SRV
Both hosts now refuse connections outright (verified from the prod app server).
That decommissioning is what stopped Itel and Tecno activation ingest within the
same hour on 2024-11-20; everything since has arrived via manual CSV upload.
Neither service has produced a row in 21 months and neither can again.
Removed:
- both service classes
- ScheduledTasks.checkItelImeiActivation / .checkTecnoImeiActivation, their
@Autowired fields and imports (the only callers)
- the --checkItelImeiActivation / --checkTecnoImeiActivation startup args
Unaffected: ItelImeiActivationNewService and checkItelImeiActivationNew, which
target the current imwav portal and were fixed in r37467. |
|
| 37417 |
5 d 5 h |
vikas |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Whatsapp botpenguin |
|
| 37401 |
5 d 22 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Drop commented reference to the removed InvoiceFormatter |
|
| 37351 |
12 d 7 h |
ranu |
/trunk/ |
code committed for sales l3 added in bi and other model |
|
| 37340 |
13 d 4 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37314 |
17 d 5 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37292 |
20 d 3 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
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. |
|
| 37255 |
25 d 3 h |
amit |
/trunk/profitmandi-cron/ |
feat: syncHotDealFlags cron entry + dev mail outbox recipient
- syncHotDealFlags: daily mirror of model_hot_deal windows into
tag_listing.hot_deals via ModelHotDealService
- dev.properties: mail.outbox.dev.recipient (required by MailOutboxService
in non-prod)
- restore full svn:ignore list (accidentally replaced) + graphify-out |
|
| 37238 |
26 d 6 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Add --regenMarginIrns one-time CLI (dry-run default, --live to run) for generating missing IRNs on issued margin CN/DNs |
|
| 37236 |
26 d 6 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Add --cancelMarginDnIrns one-time CLI (dry-run default, --live to cancel) for margin DN IRN cancellation before corrected reissue |
|
| 37232 |
26 d 23 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Add --corrMarginCNs one-time CLI option (dry-run by default, --live to issue) invoking issueCorrectiveMarginCNs for correcting margin DNs inflated by the abs sign bug |
|
| 37173 |
32 d 6 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
PJP agenda sync failure mail: drop tarun cc |
|
| 37172 |
32 d 6 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
PJP agenda instances: nightly 23:45 sync cron + manual run arg |
|
| 37154 |
33 d 2 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
revival and focus after billing in active mode |
|
| 37128 |
41 d 3 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
revival and focust marking to fofo store |
|
| 37087 |
48 d 4 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Partner limit read-phase per-partner isolation + drop dead reject wrapper
- PartnerLimitHelper.calculateChangedPartnerLimits: wrap the per-partner body in
try/catch so one partner's bad data (null limit/util in compareTo, or a
billing-date / risk lookup failure) no longer aborts the whole read phase and
silently updates zero partners every 20 min. Mirrors the write phase's
REQUIRES_NEW isolation.
- Remove dead ScheduledTasks.rejectPriceDropsOfApprovedImeis wrapper; the
@Scheduled trigger now delegates to PriceDropBatchService. |
|
| 37058 |
52 d 5 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Add regenerateBilledInvoices CLI task (--fromTime/--toTime) to re-generate invoice PDFs over a billing window; qualify InvoicePdfModel reference after the PdfUtils/DocumentRenderer refactor |
|
| 37043 |
53 d 2 h |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
revival and focust marking to fofo store |
|