Skip to content

feat(reaping): provider default reaping rides the target Config annotation - #756

Open
JeroenSoeters wants to merge 3 commits into
mainfrom
feat/manifest-default-reaping
Open

feat(reaping): provider default reaping rides the target Config annotation#756
JeroenSoeters wants to merge 3 commits into
mainfrom
feat/manifest-default-reaping

Conversation

@JeroenSoeters

@JeroenSoeters JeroenSoeters commented Sep 4, 2026

Copy link
Copy Markdown
Collaborator

Resolve target reaping in this order: explicit target policy, provider default declared by @formae.ConfigHint on the target Config class, then the global 24-hour default. The provider declaration travels in ConfigSchema, including for remote plugins; remove the unused plugin-manifest field.

Provider-only schemas now persist across SQLite, Postgres, Aurora, and MSSQL. Re-applying without a schema preserves the stored provider default, while changes to provider defaults or explicit reaping policies are applied even when target configuration is unchanged. Invalid provider defaults fall back to the global policy; invalid explicit policies remain errors.

Validation: metastructure/schema unit suites pass after merging current main. Full SQLite, model/plugin unit, and Pkl tests pass; the shared datastore regression covers provider-only schema create/update round trips. Fresh GitHub CI also passed the live Postgres, MSSQL, and Aurora suites, including the provider-only schema round-trip regression in each.

AWS, Azure, and GCP must adopt ConfigHint/NeverReap and update their schema pins after the core version containing this annotation is published. This core change alone does not change unannotated provider schemas.

Current merge blocker: the final-head mutation job hit its 90-minute limit while processing SQLite, which ran for over 88 minutes without a completed result. Aurora, MSSQL, and Postgres mutation reports completed; later packages were not reached. Functional, property, and live datastore checks are green, but the mutation gate remains incomplete.

…ation

Reaping exists for targets whose backing infrastructure can be deleted
out of band; a cloud provider region cannot go away, so root cloud
targets must never be reaped. Until now nothing could express that per
provider: the reaping precedence designed with the reaper (explicit
per-target > provider default > global 24h) had its middle level
parsed from the plugin manifest but never wired anywhere, so every
target of every plugin fell to the global reap-after unless it
declared reaping explicitly.

The provider default now lives where the plugin author already writes
target semantics: a class-level ConfigHint annotation on the target
Config class, beside the per-field ConfigFieldHint mutability
annotations. The annotation's reaping behaviour rides ConfigSchema,
which eval already attaches to the target and admission already has in
hand, so no new transport is involved and the declaration also reaches
the agent for plugins running on remote nodes. Admission resolves
explicit over the schema's provider default over the global fallback;
an invalid declaration is logged and skipped. The ConfigSchema
preservation on re-apply now keys on the whole schema, so a provider
default survives an apply whose eval-side schema carries none.

The never-wired manifest field is removed: the manifest is package
metadata (name, version, license), and target lifecycle behaviour does
not belong there.
@JeroenSoeters
JeroenSoeters force-pushed the feat/manifest-default-reaping branch from 0d39b87 to 502717b Compare September 4, 2026 03:19
@JeroenSoeters JeroenSoeters changed the title feat(reaping): plugin-manifest default reaping reaches target admission feat(reaping): provider default reaping rides the target Config annotation Sep 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant