risingwavelabs/risingwave

Describe the bug Describe the bug Two materialized views over the same 200-row table produce identical output (200 rows each, zero differing rows), but one uses ~33x the state: internal tables state total per row UDF body has FROM, called twice 10 4,323,812 B 21,619 B UDF body has no FROM, called twice 1 129,792 B 649 B payload is a JSONB column averaging 1,542 bytes. The cause: a LANGUAGE sql UDF whose body contains a FROM clause is inlined as a correlated subquery. When such a UDF is called two or more times in the same streaming job, the optimizer unnests it into StreamHashJoin, and the argument expression becomes the join key. It then lands in stream_key, so the whole JSONB value is materialized in the join's internal state — once per call site. Calling it once produces a plain StreamProject. A UDF with the same semantics but no FROM in its body produces StreamProject no matter how many times it is called. The plan CREATE FUNCTION g_from(j JSONB) RETURNS VARCHAR LANG

Is your feature request related to a problem? Please describe. Summary The Webhook source already provides an excellent way to ingest HTTP POST events directly into RisingWave. However, many webhook providers require an initial HTTP GET verification handshake before POST events can be delivered. Examples include: Meta Graph API Facebook Webhooks Instagram Graph API WhatsApp Cloud API Messenger Platform Currently this appears to be the only missing piece preventing RisingWave from acting as a complete webhook endpoint. Current situation Today the webhook connector supports: HTTP POST ingestion HMAC validation Bearer/API key validation Secret management JSON payload ingestion This already covers most of the production requirements. However Meta requires an initial verification request: GET /webhook? hub.mode=subscribe& hub.verify_token=my-token& hub.challenge=123456789 The endpoint must: validate hub.verify_token return HTTP 200 return the value of hub.challenge as the response bo

Problem When an upstream SQL Server table has its CDC disabled (via EXEC sys.sp_cdc_disable_table) while a RisingWave SQL Server CDC source is actively streaming from it, the sync silently stops for that table: No error is raised on the RW side SELECT FROM <cdc_table> continues to return rows as of the moment of disable_table The source / table remains in a "healthy" state from RW's perspective All subsequent upstream writes are permanently invisible to RW This is a real silent-data-loss footgun. Users typically do not realize that disabling CDC upstream terminates downstream sync with zero signal. Root Cause sp_cdc_disable_table atomically drops: The change table cdc.<schema>_<table>_CT The function cdc.fn_cdc_get_all_changes_<instance> The metadata row in cdc.change_tables Debezium's SQL Server connector handles the resulting Invalid object name SQL error in SqlServerStreamingChangeEventSource#processErrorFromChangeTableQuery by: Logging a single INFO line: Table is no longer ca