matrixorigin / matrixorigin/matrixone

[Bug]: guard persisted SQL and expressions across rolling protocol downgrade

Open
#28,883 0 comments 0 reactions 1 assignee Claimed by @XuPeng-SH View on GitHub
Dominant language
Go
Stars
1.9k
Forks
311
Avg merge
1d 3h
Merged PRs (30d)
768

Description

## Problem

The IP-function compatibility change in #28800 protects transient distributed
pipelines, and its writer-side admission now protects catalog-bound
`DEFAULT`, `GENERATED`, `CHECK`, and `ON UPDATE` plan expressions while the
deployment common protocol is below v71. Two persisted paths still need a
deployment-level contract beyond that PR:

1. A `VIEW` stores SQL rather than the bound `plan.Expr`; an old CN can later
rebind the SQL locally and execute the pre-v71 IP semantics.
2. A CN that is downgraded or reintroduced after the common protocol was
raised can read an already-persisted expression locally without crossing
the remote pipeline admission gate.

The same issue applies to any future catalog consumer that evaluates persisted
SQL/expressions locally.

## Reproduction shape

During a rolling upgrade, create a persisted expression such as

```sql
CREATE TABLE t (
n DOUBLE,
ip VARCHAR(32) GENERATED ALWAYS AS (INET_NTOA(n)) STORED,
CHECK (INET_NTOA(n) <> '')
);
```

or a view using `INET_NTOA`/`INET6_ATON`. If an older CN is allowed to read or
execute the catalog object after the newer protocol has been advertised, the
old registry either cannot decode a new overload or silently applies the old
meaning of an existing overload. This is a deployment admission/lifecycle
gap, not a per-row executor failure.

## Required direction

Define one deployment-managed catalog-expression compatibility contract and
apply it to all persisted SQL and bound-expression readers/writers:

- do not raise the common protocol until every catalog reader is upgraded;
- reject CREATE/ALTER/VIEW publication and old-reader re-entry while the
contract is below the expression's required version;
- keep the check at the final catalog publication/read admission boundary, so
CREATE LIKE/COPY, ALTER replacement, restored metadata, and reattached CNs
cannot bypass it;
- add a two-generation rolling-upgrade test covering an old reader, a new
writer, a downgrade/rejoin, and the unchanged catalog/data on rejection.

This is intentionally separate from #28800's transient remote-pipeline fence;
that PR now has the minimal writer guard for bound table expressions, but a
shared catalog admission contract is needed for arbitrary old-reader
re-entry and SQL-backed views.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.