expansions: has no master-delete handler - a deleted master leaves orphaned or undeletable children

[delchev]

Summary

expansions: binds the master's create and -updated events only - no handler exists for the master's delete. What happens to the generated child rows then depends on the schema: where the FK constraint is enforced, the master cannot be deleted at all (constraint violation -> 409) with no cleanup affordance; where it is not, the children survive as orphans referencing a master that no longer exists and keep feeding rollups and reports. Either way the expansion lacks a delete story.

Found by static source review against origin/master (1dc87fb505).

Where

• GlueIntentGenerator.buildExpansions (2559-2560) - exactly two entries: OnCreate (suffix ``) and OnUpdate (`-updated`). No `-deleted`.
• events/Expansion.java.template:30 - destination is the master's topic + suffix; no delete variant exists.
• Schema note: the schema template DOES emit type: "foreignKey" structures for to-one relations (template-application-schema/.../application.schema.template), so the blocked-delete variant is the likely runtime outcome where constraints are applied. (The stale "no FK constraints at all" note in engine-intent/CLAUDE.md:394 should be corrected while here - only the table-level constraints object for multi-column unique keys is conditionally empty.)

Example

A leave request with generated day rows is deleted (or its delete is attempted). Outcome A: 409 with no way to remove the request short of manually deleting each day row first. Outcome B (no enforced constraint): orphaned day rows keep counting in balances and reports.

Proposed fix

Emit a -deleted handler that removes the generated children (the expansion already owns the child set by its own contract - "a span change replaces every child pointing at the master"). Alternatively lean on a database cascade for expansion-owned children specifically - but that is a schema-semantics decision with wider blast radius; the handler is the conservative fix.

[delchev]

Fixed in #6838.

Each expansion now also emits an OnDelete handler on the master's -deleted topic, removing the rows selected by the expansion's own back-reference — per row through the child repository, so each row's delete event fires and the roll-ups/guards downstream of the child run exactly as for a hand-deleted row. Idempotent by construction (the event is published after the master row is gone, so a redelivery finds an empty set), and no write-back to the master, whose row and count field are gone with it. No new DSL key: this completes the ownership rule the construct already declares, so an existing intent gains the behaviour by re-generating.

The database cascade the issue offers as an alternative was deliberately not taken — it fires for rows the expansion does not own, applies to hand-entered children too, bypasses the child's layer so the events the totals depend on never fire, and encodes a rule the model neither states nor can see.

One correction to the report, worth recording here. The outcome is not deployment-dependent: only outcome B can occur. The schema template does emit type: "foreignKey" structures, but SchemasSynchronizer.parseImpl drops every one of them by design — carryUniqueConstraints carries the unique keys and nothing else, because a foreign key never becomes a database constraint on this platform (referential integrity is a business-layer check, so that a constraint cannot bind insert/delete order into the schema for seeds, imports and regeneration). The rows were therefore always silently orphaned, never protected, and the blocked-delete variant is unreachable. The stale engine-intent/CLAUDE.md:394 note is corrected in the same PR — it was doubly wrong: it described FK constraint emission as pending work rather than as a settled decision, and attributed the absence to constraints: [] in the emitted schema rather than to the synchronizer that drops them.

Verified at runtime, not only in the emitted source: IntentEmissionCoverageIT publishes a real app whose Retainer expands into three monthly rows on create and has none left once the retainer is deleted (the handler compiles in the client-Java batch and connects to emission-test-Retainer-Retainer-deleted). IntentEngineIT covers the emission itself.

Docs: dirigible-io/dirigible-io.github.io#203 (merged), specification proposal IntentFile/intent-specification#41, IntentFile/intentfile.github.io#32.