Estuary autoDiscover silently skips new tables and re-versions on breaking changes

TL;DR

Set it false if downstream systems must never see binding renames, and accept that incompatible changes then fail publications instead.

Steps

1. When debugging a capture that is not picking up a new table, check autoDiscover.addNewBindings: with it false, discovery deliberately ignores new tables and only refreshes existing bindings. When a schema change causes a materialization to suddenly write to a differently named binding, check evolveIncompatibleCollections: with it true, Estuary evolved the collection and re-created the binding instead of failing the publication. Set it false if downstream systems must never see binding renames, and accept that incompatible changes then fail publications instead.

When to use

You are seeing this: When debugging a capture that is not picking up a new table, check autoDiscover.addNewBindings: with it false, discovery deliberately ignores new tables and only refreshes existing bindings. Use this skill when you run into "Estuary autoDiscover silently skips new tables and re-versions on breaking changes".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (Captures concept page): Estuary's autoDiscover has two behaviors agents routinely misread. addNewBindings=false does not just pause discovery: periodic discovers still run and update the collection specs of existing bindings, but newly discovered tables are never added as bindings, so a new table appears nowhere until someone adds it. And evolveIncompatibleCollections=true means a breaking schema change triggers an evolution: materialization bindings get re-created with new names and collection keys can change, which silently re-points downstream materializations.

Verified resolution: When debugging a capture that is not picking up a new table, check autoDiscover.addNewBindings: with it false, discovery deliberately ignores new tables and only refreshes existing bindings. When a schema change causes a materialization to suddenly write to a differently named binding, check evolveIncompatibleCollections: with it true, Estuary evolved the collection and re-created the binding instead of failing the publication. Set it false if downstream systems must never see binding renames, and accept that incompatible changes then fail publications instead.

Source URL: https://docs.estuary.dev/concepts/captures/