risingwavelabs/risingwave

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