Every scan task carries a module label: the directory that owns
the scan target. A task that scans a directory reports that directory's own
name; a task that scans one file reports its parent directory. The label
drives the timeline filter box, so typing a module name there dims every task
from the other modules.
Values come from the request, not from configuration, so the set grows with
whatever the producer asks for. Treat an unfamiliar module name as new input,
not as a fault. A module whose name contains vendor is colored
purple on the timeline by the vendored code rule, so third-party
source is easy to skip past.
Tasks with module = tests scan the test suite: either one test
file, or the whole tests directory in a single recursive task.
The directory tasks are the long ones — they read far more bytes than a
single-file scan, so they dominate the throughput track without meaning
anything is wrong.
This section is what a value-specific docs anchor points at:
module alone opens the section above, while
module = tests opens this one. The narrower anchor wins on the
tasks it names, and the key-wide one still covers every other module.
The handler marks each source message's whole fan-out as a
scan_window_processing_range event: a shaded band on the live
timeline from the first task of the message to the last. Click the band to
emphasize every task the message produced.
A band that is much wider than its tasks means the window waited — for an executor slot, or for one slow task the rest of the message could not finish without. Compare the band with the pool utilization on the Live page before blaming the scan itself.