Scans should not run concurrently, and should only run when no files are currently being processed.

[cd-rite]

This issue has evolved, and previously this issue was assuming a specific solution was needed. The goals are: Only one scan running at a time. Scans should not run while files are still being processed from the previous run. Scans should be scheduled for an amount of time after work from the previous scan is complete.

Current suggested approach: Register for queue events in scanner. Scanner can track whether queues have work by tracking task_queued and drain events. Scanner checks whether it can schedule itself based on status of either queue.

Old comment/title for reference:

NextScan should be scheduled by cargo.js on cargoQueue drain, rather than being scheduled by scanner.

Scan.js always starts a new scan when an API alarm is lowered. This is not desirable behavior.

on cargoQueue drain, schedule next scan if in "scan" mode.

Consider cancelling any running scans when an alarm is raised.

[Matte22]

@cd-rite should the last bullet, "Consider cancelling any running scans when an alarm is raised" be ignored for this issue as it it is also referenced in issue #121?

[cd-rite]

121 is referring to scheduled scans. This one is referring to cancelling an ongoing scan, which may not be straightforward.

However, I don't think it's necessary as long as our queues are paused and no extra scans get scheduled.

[cd-rite]

Another thought, when cargo drains, I think we also DONT want to schedule a scan if one is already running. Soooo.... this has now got more complicated. Also: If a scan runs, and finds no new files, then it should schedule the scan itself (if no scan is currently scheduled AND there is nothing queued), since cargo will never drain if queue is already empty (and so will never schedule another scan).

[Matte22]

Yup! currently working on a solution to that!