posthog-feat-schema-ingestion-block

Based on#42450
SegmentDesign-and-build
Typefeature
## Task

Customers want the ability to actually enforce event schemas. Today they're advisory, so events violating a schema still flow through and downstream queries see missing or wrong-typed values. Add an opt-in "reject" mode per event definition: when an event is missing a required property or has a value that can't be coerced to the configured type, drop it at ingestion and surface a warning a user can find in the data mgmt UI to debug. Build it end-to-end (API, ingestion pipeline, data mgmt UI).

## User stories / requirements

- A user can flip an event definition into "reject" mode through the existing event-definitions API, and a subsequent read returns the new value. The toggle round-trips through the API surface.
- Partial updates are supported by the event-schemas resource so the data-management UI can swap a schema's property group in place without recreating the row.
- When the team has an event definition in reject mode with a required property, an event missing that property is dropped at ingestion with a schema-validation warning (should name the missing property).
- When a required property's value can't be coerced to the configured type, the event is dropped with a type-mismatch reason (likewise should name the offending property). Includes ClickHouse-unsafe Numeric values (Inf, -Inf, NaN, booleans, the corresponding string sentinels, empty and whitespace-only strings), i.e. values that JS can hold but ClickHouse cannot store.
- An event whose properties satisfy the schema flows through the validation step unchanged. Includes Numeric values that are valid for ClickHouse (finite numbers, negatives, zero, trimmed numeric strings), i.e. the validator doesn't over-reject valid traffic.
- Teams with no event definitions in reject mode short-circuit the validation step (events flow through regardless of whether their properties match any registered schemas). The validator shouldn't accidentally over-enforce on teams that haven't opted in.
- The event-definition schema management page shows an interactive toggle for enforcing the schema on incoming events (a checkbox or switch with a label related to enforcement / rejection / strictness).

## General instructions

- The code repo is at /repo/posthog.
- You are inside of a Docker container. You may not be able to perform all operations you would normally be able to do on a local machine. Dependencies have not been pre-installed, and you may need to install them yourself.
- You are expected to act autonomously as a software engineer to complete tasks you are given.
- Do not stop until you feel you have completed the task and your code changes can be merged.
- You may need to use software engineering skills like analyzing the codebase, researching technologies, running services, analyzing logs, etc. to complete the task. Not all tasks will be solvable by reading source code alone.

Agent Results

AgentTastefulBasicVerifierValidationRubricBloatPractTasteCheated
Oracle
7/71.001.0x5.04.0
Gemini 3.1 Pro
7/70.500.7x2.02.0
GPT-5.4
7/70.501.0x3.02.0
GPT-5.5
7/70.501.1x3.03.0
Opus 4.7
7/70.500.9x3.02.0
Opus 4.8
7/70.500.9x3.03.0
Sonnet 4.6
7/70.500.7x2.03.0
Sonnet 5
7/70.500.8x3.03.0
Kimi K2.6
5/70.500.7x3.03.0
Gemini 3.5 Flash
3/70.000.7x2.02.0
GLM-5.2
3/70.000.7x2.02.0
No-Op
0/70.00
Agent details

Verifier Tests

Gemini 3.1 Pro0/0

Validation Stories

Gemini 3.1 Pro7/7

Rubric Criteria

Gemini 3.1 Pro1/2
Fail → Pass
rubric_validator_mirrors_clickhouse_coercion_semantics
rubric_manager_caches_per_team_with_lazy_loader

Taste Scores

Patch Bloat0.7x
299 agent / 426 oracle SLOC, 17 / 16 files(raw: 1.8x)
Practice Alignment — 2.0/5
2
style consistency
2
pattern adherence
2
library usage
2
abstraction level
3
documentation fit
Relative Taste — 2.0/5
2
minimality
2
approach quality
1
hygiene
2
fluency
2
craftsmanship

Agent Patch