A downstream alert toggle may still leave data consumers uninformed

An OpenMetadata issue reports that a table alert with Notify Downstream enabled reached the changed table's owner but not owners of downstream assets. A test-case alert reached both groups. For a schema change, that silent recipient gap matters more than whether the toggle looks enabled.

Diagnose the boundary

Build a small test with table A feeding table B and different owners. Confirm lineage, subscription destinations and recipient addresses. Trigger an ordinary table change, then compare delivery logs for A and B owners. Repeat with a test-case alert as a control. The report reproduces this on 2.0.4 and 2.1.0-rc1; it does not establish behavior for every release or alert source. Check the installed version before declaring the control broken.

Decide the next safe change

Until the tenant proves delivery, use a second change notification path for critical downstream consumers. Record who is accountable for acknowledging the change and how far along lineage an alert should travel. Keep a test that checks both first-hop and deeper owners when the product is upgraded. A lineage graph with no notification evidence is documentation, not an operating warning system.

Evidence boundary

Issue reports 2.0.4 and 2.1.0-rc1 reproductions for table-source alerts; test-case alerts were a control that reached downstream owners. The official 2.0.x guide documents the intended owner routing and notes that fixed external destinations do not resolve downstream recipients.

Adovo’s view

A notification control is defined by who received it, not by a switch in a form. For data contracts, missed recipients create the incident. Test delivery with a real downstream owner before trusting the graph as an escalation path.