I also have the same understanding but I think if we skip replicating
some table due to the reason that the corresponding publication has
not been refreshed then it is better to LOG that information instead
of silently skipping it.
By skipping it, I mean the apply worker does not try to do anything with the changes for the missing table since the worker simply cannot apply it and only fails.
But I agree with you about logging it, the patch currently logs such cases as warnings instead of errors.
I can make it LOG instead of WARNING, just wanted to make something different than ERROR.
Do you have any use case in mind where the user has added a table to
the publication even though she doesn't want it to be replicated? One
thing that came to my mind is that due to some reason after adding a
table to the publication, there is some delay in creating the table on
the subscriber and then refreshing the publication and during that
time user expects replication to proceed smoothly. But for that isn't
it better that the user completes the setup on the subscriber before
performing operations on such a table? Because say there is some error
in the subscriber-side setup that the user misses then it would be a
surprise for a user to not see the table data. In such a case, an
ERROR/LOG information could be helpful for users.
I don't really see a specific use case for this. The delay between creating a table on publisher and then on subscriber usually may not be even that long to hurt anything. It just seems unnecessary to me that apply worker goes into a failure loop until someone creates the table on the subscriber, even though the table will not be replicated immediately.
Users also shouldn't expect for such tables to be replicated if they did not refresh the publication. That will not happen with or without this change. So I don't think it would be a surprise when they see their new table has not been replicated yet. This issue will also be visible in the logs, just not as an error.
And if users decide/remember to refresh the publication, they cannot do that anyway if the table is still missing on the subscriber. So the REFRESH PUBLICATION command will fail and then users will see an error log.