Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
instructor | 8ecccdc | Apr 12 2026, 02:58 AM |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix prepared a fix for the issue found in the latest run.
- ✅ Fixed: Lazy
hooksresolution fails viagetattron submodule- Updated the lazy attribute mapping so
instructor.hooksimports theinstructor.core.hookssubmodule directly instead of usinggetattr(instructor.core, "hooks").
- Updated the lazy attribute mapping so
You can send follow-ups to the cloud agent here.
Reviewed by Cursor Bugbot for commit b743282. Configure here.
| "AsyncInstructor": (".core.client", "AsyncInstructor"), | ||
| "from_openai": (".core.client", "from_openai"), | ||
| "from_litellm": (".core.client", "from_litellm"), | ||
| "hooks": (".core", "hooks"), |
There was a problem hiding this comment.
Lazy hooks resolution fails via getattr on submodule
High Severity
The lazy entry "hooks": (".core", "hooks") tries to resolve instructor.hooks by importing instructor.core and then calling getattr(module, "hooks"). However, instructor.core.__getattr__ only handles names in its _LAZY_ATTRS dict, which contains "Hooks" and "HookName" but not the submodule name "hooks". Unlike the from .core import hooks import statement (which has a submodule fallback), getattr on a module with __getattr__ does not attempt submodule resolution per PEP 562. This causes AttributeError when accessing instructor.hooks unless another lazy attribute has already triggered importing instructor.core.hooks as a side effect. The mapping needs to be (".core.hooks", None) to directly import the submodule.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit b743282. Configure here.


Fixes #2205.
Summary
instructor.__init__,instructor.core, andinstructor.processinglazy so bareimport instructordoes not eagerly import patching, response processing, and provider helpersinstructor.processing.responseor provider util modulesinstructor.processing.responseto import exceptions without re-entering eagercorepackage initializationVerification
uv run pytest tests/test_import_lazy_loading.py tests/test_patch.py tests/test_process_response.py tests/test_xai_optional_dependency.py -quv run ruff check instructor/__init__.py instructor/core/__init__.py instructor/processing/__init__.py instructor/processing/response.py tests/test_import_lazy_loading.pyimport instructorloaded about99 MBRSS /1161modulesimport instructorloaded about15 MBRSS /57modulesNotes
tests/test_auto_client.pyand provider-specific response conversion tests were environment-dependent missing-provider/live-provider issues, not regressions from this lazy import change.Note
Medium Risk
Changes package import mechanics via
__getattr__-based lazy exports, which can subtly affect runtime import order, optional dependency detection, and attribute resolution. Risk is mitigated by regression tests but could surface in edge-case import patterns.Overview
Switches
instructor,instructor.core, andinstructor.processingto lazy-load public exports via module-level__getattr__/__dir__, avoiding eager imports of patching/response/provider code on bareimport instructorwhile keeping the same top-level API surface.Refactors optional provider exports (e.g.
from_anthropic,from_gemini, etc.) to register as lazy attributes only when dependencies are present, and adjustsprocessing.responseto import exceptions directly from..core.exceptionsto prevent triggering core package initialization.Adds a subprocess-based regression test (
tests/test_import_lazy_loading.py) ensuring heavy modules aren’t imported eagerly and that accessing a top-level export (e.g.instructor.patch) triggers the expected on-demand import.Reviewed by Cursor Bugbot for commit b743282. Configure here.