Subversion Repositories SmartDukaan

Last modification

• Rev 37565 2026-09-10 03:00:55
• Author: amit

• Log message:

  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.