Subversion Repositories SmartDukaan

import com.smartdukaan.cron.monitored.ImeiActivationGauges;

	@Autowired

	private ImeiActivationGauges gauges;

	/**

	 *

	 * not due tomorrow either -- it comes back the day after, a two-day cadence. DAYS=0

	 * Within a pass the snapshot already guarantees one ask per imei, so this constant

	 * only governs the gap BETWEEN passes.

	 */

	private static final int DAYS = 0;

	/**

	 *

	 * Replaces the separate oppo() and realme() jobs. Nothing else in this class runs a

	 * browser, so with a single caller there is exactly one ChromeDriver alive at any

	 * moment -- down from four. Peak concurrent drivers is what triggers the OOM killer

	 * on this box, not average driver-seconds.

	 *

	 * ONE FULL PASS PER DAY, and no imei is asked twice inside a pass. Both pools are

	 * snapshotted before any browser starts and the pass walks those lists to the end;

	 * it never re-queries. That is the whole fix for the re-ask loop:

	 *

	 *   A failed lookup writes no row (dateMap.put is only reached on the success path),

	 *   five minutes later. Measured 29-Aug: realme issued 4,524 requests against just

	 *   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, which caused more requests.

	 *

	 * A snapshotted pass bounds that structurally: a failure costs one retry TOMORROW,

	 * never one in five minutes, no matter how the far end misbehaves.

	 *

	 * Sizing, measured on prod 2026-08-31 for a pass starting at midnight: oppo 4,133 and

	 * realme 2,118 imeis, which at 10.2s and 14.2s each is 11.7h + 8.4h = 20.1 hours of a

	 * single thread -- an 84% duty cycle. It fits, but there is NO slack. If per-imei

	 * seconds regress the pass will not finish and the tail rolls into the next day.

	 * Watch the "Daily pass finished" line: counts short of the "starting" line are the

	 * signal, and the lever is DAYS=1 (halves the work) rather than a second thread.

	 *

	 * Excluding stock billed today or yesterday is correctness, not capacity -- measured,

	 * hours has essentially never been activated yet, and the cohort data agrees: the

	 * sold-within-180-days cohort returns a date on 2.4% (vivo) to 8.4% (oppo) of

	 * lookups, against 43-97% for stock sold over a year ago.

	 *

	 * ⚠ Realme's ceiling is a REQUEST-VOLUME ceiling, not a CPU one. realme.com stops

	 * serving the captcha widget as the day's request count climbs: measured 920/day ->

	 * 0.3% canvas timeouts, 3,467/day -> 28%, 4,524/day -> 75%, resetting at midnight --

	 * while oppo on the same box, same driver count, same widget vendor, at 4,350/day had

	 * ZERO timeouts across all 24 hours, on a box loaded at 0.9 of 6 cores. Realme's own

	 * canvas wait is 15s against oppo's 8s, so the longer wait is the one expiring. A

	 * daily pass puts realme near 2,127 requests/day, between the 920/day point where it

	 * was healthy and the 3,467/day point where it was 28% blocked -- so expect SOME

	 * blocking and judge the change on dates written, not on timeout count. What the

	 * pass guarantees is that blocking can no longer feed itself.

	 *

	 * Oppo and realme alternate chunk by chunk, so whichever pool still has work keeps

	 * the thread busy once the other is exhausted.

	 */

	public void checkBrowserImeiActivation() {

		List<String> oppo = pendingFor("Oppo");

		List<String> realme = pendingFor("Realme");

		gauges.beginPass("Oppo", oppo.size());

		try {

			if (oppo.isEmpty() && realme.isEmpty()) {

				LOGGER.info("Oppo and Realme: nothing due today, not starting a browser");

				return;

			}

			int oppoDone = 0;

			int realmeDone = 0;

			while (oppoDone < oppo.size() || realmeDone < realme.size()) {

				realmeDone += runChunk("Realme", realme, realmeDone, realmeImeiActivationService::updateActivationDate);

			}

		} finally {

			// In a finally so a pass killed part-way still publishes what it managed.

			// A truncated pass is exactly the case worth alerting on, so it must not be

			// the case that silently reports nothing.

			gauges.endPass("Oppo");

			gauges.endPass("Realme");

		}

	 * One driver session's worth of one brand, taken from a list that was snapshotted

		List<String> chunk = pool.subList(from, Math.min(from + CHUNK, pool.size()));

		runBrand(brand, chunk, batch);

		return chunk.size();

	/**

		LOGGER.info("{} imeis {}", brand, imeis);

		try {

			batch.run(imeis);

		} catch (Exception e) {

			gauges.error(brand);

			LOGGER.error("{} activation batch failed, continuing with the next brand", brand, e);

		}

	}

	@FunctionalInterface

	private interface ImeiBatch {

		void run(List<String> imeis) throws Exception;

	}

	/**

	 * Everything due for one brand today, as a single list.

	 *

	 * The secondary/tertiary split is an artefact of there being two join paths to a

	 * serial (transaction.lineitem vs fofo.fofo_line_item), not two kinds of work: both

	 * funnel into the same updateActivationDate -> checkWarranty -> saveActivation path.

	 * They were separate jobs with separate batch sizes, which is what made the split

	 * visible at all. A pass walks the whole list to the end, so nothing can be starved

	 * by ordering and a plain concatenation is enough.

	 *

	 * The pools are disjoint by construction -- the secondary query excludes anything

	 * with a FofoLineItem -- so distinct() is cheap insurance, not a fix for a known

	 * selectImeiActivationPendingByBrand (same named query, same parameters), so the

	 * brand-generic call is used for every brand.

	 */

	private List<String> pendingFor(String brand) {

		List<String> pool = new ArrayList<>();

		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrand(brand, DAYS, POOL_CAP)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));

		pool.addAll(activatedImeiRepository.selectImeiActivationPendingByBrandTertiary(brand, DAYS, POOL_CAP)

				.stream().map(ImeiActivationTimestampModel::getSerialNumber).collect(Collectors.toList()));

		if (pool.size() >= POOL_CAP) {

			LOGGER.warn("{} pool hit the {} cap -- the pass will not cover everything due today", brand, POOL_CAP);

		}

		return pool.stream().distinct().collect(Collectors.toList());