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);
        @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);
                });
                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);
                        }
                }
        }

}