Skip to content

Materialization scheduler: GC + integration state-machine transition coverage (fast-follow to #888) #895

Description

@girishjeswani

Follow-up test coverage split out of #888 per review, to keep that PR focused on the config-parity core and orchestrated-safety work while landing these additively.

Two areas the current scheduler suites don't cover yet:

Garbage collection

  • Drop-failure pathdeleteMaterialization with dropTables: when the physical table drop fails, the record is still deleted and the failure is metered (assert both).
  • Staging-table cleanup on failed/cancelled builds — a build that fails or is cancelled mid-run must not orphan _staging tables. If they can leak, a test should document the current behavior.
  • Physical tables on environment/package deletedeleteByEnvironmentId removes the records; confirm whether the physical tables leak. If the leak is intentional, a test asserting it documents the decision.

State-machine transitions (integration level)

The unit specs cover the per-tick guards; these transitions each warrant an integration test through the real store:

  • A cron edit between ticks re-arms from now (no stale fire from the old cadence).
  • A package unload/reload prunes and re-anchors without a spurious fire.
  • A FAILED fire retries at the next cron occurrence (cron cadence), not every tick.
  • maxFiresPerTick carryover — a capped package fires on the following tick.

Neither area changes the design; they harden coverage around the standalone materialization scheduler introduced in #888.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions