Request icon
Log icon
If icon
SlackIncomingWebhook icon
Pause icon
Fail icon
SchemaCreate icon
BatchCreate icon
Query icon
Delete icon
Schedule icon

Repair Weaviate autoschema datatype drift behind a verified canary

Detect Weaviate autoschema datatype drift and repair it behind approval with schema and filtered-query verification.

Categories
Data

Safety

An undeclared Weaviate class can accept a successful batch while auto-schema stores a date as text. The retrieval pipeline then reports ingestion success but date filters return no objects. This flow protects the existing class and writes only to a new versioned class after approval.

Guard What it stops
Live schema diff A count-only canary passing a wrongly typed class
Dry-run and auto-remediate gates An accidental class creation or re-ingestion
Pause plus post-pause schema read Acting on a stale approval snapshot
SchemaCreate under a versioned name Mutating or deleting the existing class
Schema read-back and filtered Query Treating a successful write as proof of a usable schema
Probe Delete Leaving verification data in the repaired class

This blueprint was created by zkasuran.

How it works

  1. read_live_schema (io.kestra.plugin.core.http.Request) reads /v1/schema/<class> from the target Weaviate instance. schema_diff records the datatype, tokenization, index flags and vectorizer values from that live response.
  2. detect_drift compares the live response with the committed probe contract: title and tenant are tokenized text, eventDate is filterable date plus the class vectorizer is none.
  3. A finding is reported to Slack. The flow stays read-only unless auto_remediate=true and dry_run=false; the disabled schedule always forces those safe values.
  4. approve_schema_repair (io.kestra.plugin.core.flow.Pause) presents the diff for approval. reread_before_write reads the old class again and stale_plan_gate refuses the write if its bytes changed while approval was pending.
  5. create_versioned_schema (io.kestra.plugin.weaviate.SchemaCreate) creates the typed class and reingest_probe (io.kestra.plugin.weaviate.BatchCreate) writes the bounded probe batch into it.
  6. read_repaired_schema verifies every committed property setting. filtered_probe_query (io.kestra.plugin.weaviate.Query) requires both a date range and tenant where clause to return the probe. The run fails if either check misses plus the probe is deleted on both success and failed verification paths.
  7. The errors block sends a Slack alert for an API, schema or verification failure.

What you get

  • A live schema diff that distinguishes a populated but incorrectly typed class from a healthy class.
  • A dry-run report and explicit approval before creating a versioned repair class.
  • A real SchemaCreate plus BatchCreate repair path, with schema read-back and a date-range/tenant query as the recovery proof.
  • Probe cleanup and Slack alerts for failed runs.

Who it's for

Platform and data teams operating Weaviate ingestion pipelines where a successful batch response must also mean that filtering and retrieval semantics remain usable.

Why orchestrate this with Kestra

Weaviate stores schema and data but does not coordinate a reviewable drift plan, an approval pause, a versioned repair plus an independent query proof. Kestra provides those steps as an auditable execution with safe trigger inputs and an error notification path.

Tested end to end

Tested on Kestra 2.0.5 with Weaviate 1.25.0. The test fixture reproduces autoschema by batch-inserting eventDate=17/10/2026 into an undeclared class, which creates eventDate as text; a GraphQL date-range query returns no probe. Remediation re-ingests the same probe with the normalized ISO value 2026-10-17T12:00:00Z into the typed versioned class. Counts and query results are read from Weaviate's REST and GraphQL APIs.

Case Execution Result
Healthy control 2qMzrsehOYkQ0ftEvGEIvU Healthy class spared
Degraded dry run 2zLjqIm5iKvDbRhmwirapt Drift reported with no write
Declined approval 3wEyoJXmlA9HcPNBpVeMsw No class or object write
Remediation 19D2peSAghuloZUI6riDZn Typed class and filtered probe verified
Repeat 5SEIitSJM09aTpUxEsVBEY Existing version reconciled
Ineffective write 4EaYZjvU7dvEFL9F0Ezjgg Failed schema verification
Race during approval 3ZAkgXzwWsJN0jx8Tergor Stale plan refused

Prerequisites

  • Kestra 2.0.5 with the Weaviate plugin and a Weaviate 1.25+ instance reachable from the worker.
  • Permission to read /v1/schema, create a class, batch-create objects, query GraphQL and delete the probe objects.

Secrets

  • WEAVIATE_API_KEY: bearer credential when anonymous=false.
  • SLACK_WEBHOOK_URL: incoming webhook for findings and failures.

Inputs

Input Purpose
weaviate_url Weaviate endpoint
anonymous Whether to omit the API key
degraded_class Class whose live schema is diffed
repaired_class Versioned class created by remediation
probe_title, probe_date, probe_tenant Bounded re-ingestion and verification values
dry_run Report only when true
auto_remediate Arm the approval and write path

Quick start

  1. Start Weaviate and configure the two secrets; set anonymous=true for a local fixture when appropriate.
  2. Batch-insert a probe into an undeclared degraded_class so autoschema creates the class, then run with the defaults to inspect the diff.
  3. Set auto_remediate=true and dry_run=false, approve the displayed diff plus inspect the schema read-back and filtered query.
  4. Confirm the probe was deleted from the versioned class and keep the original class for a separately planned data migration.

How to extend

  • Replace the bounded probe object with the production batch produced by the upstream source and keep a stable versioned class name per schema revision.
  • Add additional committed properties to the SchemaCreate fields and both schema diff expressions before enabling the schedule.
  • Put a source-specific re-ingestion task before BatchCreate when the original class contains more than the canary batch.

Limits: SchemaCreate exposes property datatypes but not arbitrary Weaviate module configuration. This blueprint therefore commits and verifies the server defaults for tokenization, index flags and the none vectorizer; use a dedicated schema-management plugin when a different vectorizer or non-default index setting is required. It repairs into a versioned class and proves the supplied probe batch, not a full historical backfill.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.