Re-read one connection's catalog INSIDE a scope that is already open (MJ-RUN-46).
A scope's catalog is memoised from when it was loaded. A first discovery loads it before the
connection has any rows, so it holds none — and Persist then writing 888 rows does not disturb
it. The two-pass discovery heal exists to sample the objects that "came into existence in the
Persist that follows", and IntegrationEngineBase.RefreshCatalog refreshes only the SHARED
catalog, which is no longer where a connection's own rows live. So without this the heal re-read
an empty catalog and sampled nothing. Observed on the sandbox 2026-09-21: both passes failed
with 460+1248 IntegrationObject not found AFTER Persist had written all 888 rows; 862 of 888
objects ended with no primary key and no fields, and the run reported Success.
Eviction alone is not enough: inside an open scope the getters are synchronous and cannot
query, so an evicted connection reads as having no catalog of its own and silently falls back
to the shared one. This READS FIRST and swaps after, so the previous catalog keeps answering
until the fresh one replaces it, and a failed read leaves it in place and throws.
The connection's field rows are stale by definition once its catalog has been rewritten, so the
ones nobody holds are dropped. A row a running map has pinned is left to that map; it goes at
the connection's next refresh, which every sync does at its head.
Call sites: the head of every sync run, and the discovery heal, right after it refreshes the
shared catalog and before its second Introspect + Persist.
Re-read one connection's catalog INSIDE a scope that is already open (MJ-RUN-46).
A scope's catalog is memoised from when it was loaded. A first discovery loads it before the connection has any rows, so it holds none — and Persist then writing 888 rows does not disturb it. The two-pass discovery heal exists to sample the objects that "came into existence in the Persist that follows", and
IntegrationEngineBase.RefreshCatalogrefreshes only the SHARED catalog, which is no longer where a connection's own rows live. So without this the heal re-read an empty catalog and sampled nothing. Observed on the sandbox 2026-09-21: both passes failed with 460+1248IntegrationObject not foundAFTER Persist had written all 888 rows; 862 of 888 objects ended with no primary key and no fields, and the run reported Success.Eviction alone is not enough: inside an open scope the getters are synchronous and cannot query, so an evicted connection reads as having no catalog of its own and silently falls back to the shared one. This READS FIRST and swaps after, so the previous catalog keeps answering until the fresh one replaces it, and a failed read leaves it in place and throws.
The connection's field rows are stale by definition once its catalog has been rewritten, so the ones nobody holds are dropped. A row a running map has pinned is left to that map; it goes at the connection's next refresh, which every sync does at its head.
Call sites: the head of every sync run, and the discovery heal, right after it refreshes the shared catalog and before its second Introspect + Persist.