Subversion Repositories SmartDukaan

package com.smartdukaan.cron.scheduled;

import com.spice.profitmandi.dao.repository.fofo.ActivatedImeiRepository;

import org.apache.logging.log4j.LogManager;

import org.apache.logging.log4j.Logger;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;

import java.time.LocalDate;

import java.util.List;

import java.util.Map;

@Service

public class OppoImeiActivationService {

	private static final Logger LOGGER = LogManager.getLogger(OppoImeiActivationService.class);

	private static final String BRAND = "Oppo";

	@Autowired

	ActivatedImeiRepository activatedImeiRepository;

	@Autowired

	CheckOppoWarrantyTask checkOppoWarrantyTask;

	public void updateActivationDate(List<String> imeis) throws Exception {

		Map<String, LocalDate> imeisDateMap = checkOppoWarrantyTask.checkWarranty(imeis);

		imeisDateMap.forEach((serialNumber, date) -> {

			LOGGER.info("Serial Number {} Date {}", serialNumber, date);

			activatedImeiRepository.saveActivation(serialNumber, date != null ? date.atStartOfDay() : null);

		});

		// NOTHING answered means the failure was OURS, not a verdict on these imeis, so do

		// not stamp them. A per-imei failure is normal and still rests below; a whole chunk

		// failing is infrastructure -- a dead driver, an unreadable jar resource, the site

		// refusing every request -- and stamping it spends the pool on an outage. That is

		// exactly what happened on 2026-09-22: a ZipException on every WebDriver command

		// burned 3,920 realme and 4,824 oppo imeis in one day for 0 and 96 dates against a

		// normal 76-100%, and because the rows were stamped they will not be re-asked until

		// their rest expires. Leaving them unstamped costs a re-ask of the SAME chunk on the

		// next tick, which is loud and self-limiting, instead of quietly consuming the day.

		if (imeisDateMap.isEmpty() && imeis.size() > 1) {

			LOGGER.error("{} answered none of {} imeis - treating as infrastructure failure and"

					+ " leaving them unstamped rather than resting the whole chunk", BRAND, imeis.size());

			return;

		}

		restUnanswered(imeis, imeisDateMap);

	}

	/**

	 * Stamp the imeis that never reached an answer, so the chunk advances past them.

	 *

	 * checkWarranty already records a null date for a lookup the portal ANSWERED with no

	 * activation, so what is left here is genuine failure: an exception, a captcha never

	 * broken, a dead driver. Those wrote no row at all, which left createTimestamp

	 * untouched and the imei immediately due again.

	 *

	 * Under the old snapshotted once-a-day pass that was harmless -- the pass had already

	 * walked past them, so they came back tomorrow either way. Under a 20-second tick the

	 * pool query IS the cursor, so an unstamped imei is handed back twenty seconds later

	 * and the batch never advances. That is the 4.5-asks-per-imei runaway measured on

	 * 29-Aug, and at this cadence it is 15x tighter than the 5-minute version that caused it.

	 *

	 * saveActivation(serial, null) bumps createTimestamp without claiming a date, and it

	 * cannot erase one: the setter is only reached for a non-null timestamp. So a failure

	 * costs exactly one retry, tomorrow.

	 */

	private void restUnanswered(List<String> imeis, Map<String, LocalDate> answered) {

		for (String serialNumber : imeis) {

			if (!answered.containsKey(serialNumber)) {

				LOGGER.info("Serial Number {} unanswered, resting until tomorrow", serialNumber);

				activatedImeiRepository.saveActivation(serialNumber, null);

			}

		}

	}

}