Retry provider registration after installing requirements

[BillJr99]

Summary

Fixes a chicken-and-egg bug that made it impossible for a code provider to import its own declared requirements: at the top of its code: block — e.g. a Gmail provider declaring google-api-python-client and starting with from google.oauth2.credentials import Credentials failed at startup with:

exec_provider_code error in /app/tools/gmail-filters.yaml: No module named 'google'
Skipping provider /app/tools/gmail-filters.yaml — register_provider failed: No module named 'google'

Root cause

At startup, register_provider() ran before run_provider_setup(). For code providers, registration exec()s the code block — running its top-level imports — before the requirements are pip-installed. On failure, the loop skipped the provider entirely, so the requirements were never installed and restarting could never self-heal.

Fix

The startup loop body is extracted into bootstrap_provider():

• Registration still runs first, so a slow or failing build never blocks tools from being advertised (unchanged behavior for package/repository/REST providers).
• When registration fails, the provider's requirements/setup now run, and registration is retried once before the provider is skipped.
• bootstrap_provider() never raises — one bad provider still can't crash startup.

Testing

• New TestBootstrapProvider unit tests cover the happy path, the install-then-retry path, and all failure-ordering cases (6 tests).
• Includes an end-to-end test exec'ing a code block whose import only succeeds after the (mocked) pip install, asserting the tool lands in the registry.
• Verified against the original failing gmail-filters.yaml in a clean environment with no google module: registration fails once, the three Google packages install, and the retry registers all four tools.
• Full suite passes: 432 tests.

https://claude.ai/code/session_01WnK1rtXGHDCNpsycAvxFqC

---

Generated by Claude Code