If an Estuary Snowflake materialization using Snowpipe streaming fails with malformed name blob registration errors, check whether the destination table was altered or dropped and recreated outside of Estuary: that breaks the streaming channel's schema tracking. Do not hand-edit the materialized tables; let Estuary's schema evolution manage them. Once in this state the materialization needs a backfill to clear the recovery. Workaround for investigation: compare the table DDL against the collection schema to find the out-of-band change.

Context: GitHub issue estuary/connectors#4030 (closed, 7 comments): the Snowflake Snowpipe streaming materialization failed with attempting to register blob with malformed name and an undocumented error code 89. Snowflake support confirmed code 89 is an internal schema evolution error: when the destination table's schema is modified outside of the streaming channel, for example with a manual ALTER TABLE, the channel detects a mismatch during blob registration and fails with only the raw numeric code. It can also happen if the table was dropped out-of-band, which changes the encryption key the bdec files were written with.