Subversion Repositories SmartDukaan

Last modification

• Rev 37482 2026-08-31 17:59:36
• Author: amit

• Log message:

  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.