data_updater_v2.tables.issues

issues.py — the pipeline’s own record of what needs doing: an issue opens when a section observes something to act on (a new listing with no history yet, a change no event explains, a vendor that does not carry a listing), stays open — one per identity — while it is seen again, and closes when the work that fixes it is proven done, or is waived. Kept beside the data (schema maintenance in the pipeline database), so a fix and its proof can commit together. nc-data’s maintenance plane (nc_data/models/maintenance/base.py) is the reference; this is it in our vocabulary:

issue          one occurrence of one identity — the section, the kind, the table and the
               listing it concerns (our ``id`` / ``global_id`` / ``symbol``) and the rest of
               its key — with what fixes it (``action``: the DataClient method a job runs)
assessment     one revision of a verdict on an identity (complete, not due, unsupported,
               waived ...): what may close, defer or suppress an issue
attempt        one claimed run of the work an issue asks for (a backfill job's), leased,
               then verified
issue_event    every change of an issue, append-only: detected, seen again, resolved ...

Differences from nc-data, ours by design: the target is named in our ids (table_name, listing_id, global_id, symbol) rather than a generic type/name pair, so a job asks “what is open for this listing” directly; capability is action, the method that fixes the issue; the domain is the DataClient section (universe, daily, splits …).

Classes

Assessment

Bases: Base

One revision of a verdict on an identity: what may close, defer or suppress an issue.

Attempt

Bases: Base

One claimed run of the work one issue occurrence asks for: leased, run, verified.

Issue

Bases: Base

One occurrence of one issue identity: open until the work is proven done or waived.

IssueEvent

Bases: Base

One append-only event of one issue occurrence.