---
title: Detect a table no importer is scheduled to fill
type: task
status: draft
description: >-
  The sixth cause of a blank data-view cell: nothing schedules the importer at all. Deferred from
  the blank-cell provenance work because no machine-readable table-to-job map exists and a crontab
  sweep is structurally wrong.
base_uri: user:task/league/data-views/detect-importer-never-scheduled.md
created_at: '2026-09-22T17:18:23.229Z'
entity_id: 8942125b-b9a3-4161-9e70-01811e7ba421
owner_identity_uri: █████████████████████████
priority: Medium
public_read: true
tags:
  - user:tag/league-xo-football.md
updated_at: '2026-10-03T03:42:54.068Z'
visibility_analyzed_at: '2026-11-05T23:48:47.242Z'
---

# Detect a table no importer is scheduled to fill

## Why this is its own task

This is the sixth cause of a blank data-view cell, deferred out of
[[█████████████████████-█████████████-█████-████-████-████████]], which handled the other five.
It was deferred on a structural finding rather than on effort: the detector the obvious approach
suggests cannot work.

## The finding that blocks the obvious approach

**A crontab sweep is structurally wrong, not merely incomplete.** Several importers migrated off
crontab onto user-base `scheduled-command` entities and appear in no crontab at all.
`libs-server/source-week-write-coverage.mjs` records that a crontab sweep therefore reads as
"nothing schedules this" for a table whose importer runs perfectly well — which is the failure
direction that looks like a finding. A sweep would generate confident false alarms for exactly the
tables that were modernized.

**No machine-readable table-to-job map exists.** There is no declaration anywhere that says which
job writes which table, so the association has to be established before it can be checked.

**`EXPECTED_WEEKLY_PROJECTION_SOURCES` is the hand-authored precedent.** It is the existing shape
for "these sources are supposed to produce rows" — a maintained list rather than a derived one.
Whether that is the right model to generalize, or whether the declaration belongs on the importer,
is the first thing to settle.

## What the sibling causes already cover, so this does not

The registered data checks cover a table that is filled but SHORT. What none of them can see is a
table nothing is scheduled to fill at all, because every coverage check compares rows against an
expected population and a table with no writer has no expectation registered either.

## Open questions

- Where does the table-to-job declaration live — on the importer, on the scheduled-command entity,
  or in a hand-authored registry like the projection-sources precedent?
- Does the detector belong in the data-check registry, or is it a different kind of check, since it
  asks about SCHEDULING rather than about rows?
- Is the unit a table, or a (table, season) pair? An importer retired on purpose is not a defect.