I did some digging as well and think this is on the right track, with a caveat that the error from trying to attach the table in the ATC plugin too early is dropped here (ie in the ATC plugin code). The multiplexing code in the registry factory that drops errors only happens if there are multiple active plugins separated by a comma, but the call to the SQL plugin specifically just requests "sql".

In any case, the Table plugin registry needs to be aware of a table before the "attach" request is made to the SQL plugin, meaning #8233 should be reverted in favor of an alternate fix for the duplicate ATC table registration issue.

Besides the ATC plugin, there are two other paths that add tables to the registry and SQL connection:

• Built in tables:
  • Added to table registry at initialization time with a macro (template for this is here)
  • Added to SQL connection the first time it's initialized (at latest during the first query)
• Extensions that provide tables
  • Added to table registry as "external" table and SQL connection in the same code path:
    • registerExtension calls RegistryFactory's addBroadcast to tell all the registries about the extension
    • RegistryFactory calls each registry's addExternal function
    • RegistryInterface first registers the route, then calls the implementation's addExternal function, then finishes registering the extension in table registry if successful in this code block
      
      • TablePlugin's addExternal function calls the SQL plugin to attach the extension table to the SQL connection
      • SQL plugin calls back to table registry for information on the extension table here
      • This returns an empty response here because the table's route has already been registered, but it doesn't register in the list of tables yet, so there is no duplicate issue like ATC

Because ATC tables can be added and removed dynamically (including in the race with table extensions described here), they need to call SQL attach explicitly -- only the built-in tables can safely rely on database initialization to attach the tables. There are a couple paths on how to fix both this bug and the duplicate ATC table registrations:

• Have a partial pre-registration state for ATC tables similar to extensions
• Initialize the database connection before trying to register or attach anything (either in ATC code or somewhere else in osquery's init code that we know runs before ATC will)

I think the second is a much simpler fix without much downside. I'll put up a quick PR as an example, not sure how much time I'll have to actually test it

@bgirardeau-figma -- @Micah-Kolide might have a fix in flight as well.

OK I decided to go with the pending state idea instead, as it seems more correct/less hacky. I think forcing initialization in the ATC table would also mostly work, but in theory there could be (admittedly very unlikely) races where the database gets reinitialized in the middle, causing a duplicate registration again.

Here's a PR: #8324