feat(instagram): upgrade SDK to 2.0.0, fix helpers import, add pytest unit + integration tests#327
Conversation
… unit + integration tests - Fix ModuleNotFoundError: add sys.path.insert so actions/ subpackage can resolve helpers - Use explicit config path in Integration.load() to avoid CWD-relative resolution - Bump autohive-integrations-sdk to ~=2.0.0; update all response.data accesses - Replace old context.py/test_instagram.py with conftest.py, 57 unit tests, and live integration tests
🔍 Integration Validation ResultsCommit: Changed directories:
|
…type fields, revert __init__.py to simple imports
|
All 57 unit tests passing. Live integration tests performed against a real Instagram Business account — 13/15 passed, 2 skipped (comment structure and lifecycle tests skipped due to no comments on test account posts, not a code issue). |
|
fully working on beta too! |
There was a problem hiding this comment.
Update after checking this against the repo's multi-module integration pattern.
Verification I ran for the instagram integration:
uv pip install -r instagram/requirements.txt✅python ../autohive-integrations-tooling/scripts/validate_integration.py instagram✅ with one expected advisory warning about explicitIntegration.load(<path>)python ../autohive-integrations-tooling/scripts/check_code.py instagram✅pytest instagram/ -v✅ 57 passedpytest instagram/tests/test_instagram_integration.py -m integration -q✅ 15 skipped locally becauseINSTAGRAM_ACCESS_TOKENis not set
Correction to my original framing: the import actions side-effect registration pattern is intentional for multi-module integrations and matches existing integrations in this repo. If the Autohive runtime contract is to add the integration directory to sys.path and import the entry point by filename stem (instagram), then the import/registration concern is not a merge blocker.
The inline comment now frames this as a loader-contract hardening concern only: if the runtime ever loads the entry point by file path under a different module name, actions can register on a second module instance. That is worth confirming or optionally guarding with a small regression test, but it is conditional on loader behavior.
Remaining non-blocking follow-up: get_comments now returns total_count, and tests assert it, but get_comments.output_schema in config.json only declares comments and next_cursor. It would be good to add total_count so schema/docs match runtime output.
|
|
||
| # Import actions to register handlers | ||
| from instagram import actions # noqa: F401, E402 - registers action handlers | ||
| import actions # noqa: F401, E402 - registers action handlers |
There was a problem hiding this comment.
Update after checking the repo's multi-module integration pattern: this side-effect import is intentional and is consistent with existing integrations such as facebook, aws, and humanitix, where the entry module imports actions for registration and action modules import the integration object from the entry module.
So I would not treat this as a definite bug solely because Instagram is multi-module, and this should be fine if the Autohive runtime contract is to add the integration directory to sys.path and import the entry point by its filename stem (instagram).
The only remaining concern is a loader-contract edge case: if the runtime ever loads the configured entry point by file path under a different module name, the action modules' from instagram import instagram can import this file a second time and register handlers on a different Integration instance. I reproduced that local edge case with importlib.util.spec_from_file_location("instagram_entry", "instagram/instagram.py").
Given the established multi-module pattern, I’d frame this as optional hardening rather than a merge blocker: either confirm the runtime always imports by module stem, or add a small guard/regression test for file-path loading. The simple guard would be to alias the running module before importing actions, e.g. sys.modules.setdefault("instagram", sys.modules[__name__]).
Superseded by updated review text: after checking the multi-module integration pattern, the import-registration concern is conditional on loader behavior and not a definite merge blocker.
|
Addressed the two follow-up items from review. 0790c70 adds sys.modules.setdefault before importing actions so the module is always aliased as 'instagram' even if the runtime loads the entry point by file path under a different name. b5f91bb adds total_count to the get_comments output_schema in config.json so the schema matches what the action actually returns and what the tests assert. |
TheRealAgentK
left a comment
There was a problem hiding this comment.
Latest changes address my prior notes:
total_countis now declared inget_comments.output_schema.- The optional file-path loader hardening was added with the
sys.modules.setdefault("instagram", sys.modules[__name__])alias before importingactions.
I re-ran local checks for instagram:
uv pip install -r instagram/requirements.txt✅python ../autohive-integrations-tooling/scripts/validate_integration.py instagram✅ with the known advisory warning for explicitIntegration.load(<path>)python ../autohive-integrations-tooling/scripts/check_code.py instagram✅pytest instagram/ -v✅ 57 passedpytest instagram/tests/test_instagram_integration.py -m integration -q✅ 15 skipped locally becauseINSTAGRAM_ACCESS_TOKENis not set
I also verified a standard importlib file-path load with the module pre-inserted in sys.modules; the returned integration object has all 8 action handlers registered.
Summary
ModuleNotFoundError: No module named 'helpers'that occurred on every action execution. Root cause: the SDK does not add the integration directory tosys.path, so theactions/subpackage could not resolvehelpers. Fixed by addingsys.path.insert(0, os.path.dirname(__file__))ininstagram.pyat load time.autohive-integrations-sdkto~=2.0.0and updates allresponse.dataaccesses acrossinstagram.py,helpers.py, and every action file to use the newFetchResponseobject returned bycontext.fetch().context.pyandtest_instagram.pytest approach with a cleanconftest.py, 57 unit tests (test_instagram_unit.py), and a full live integration test suite (test_instagram_integration.py) following the same pattern as the float integration.Changes
Bug fix
instagram.pynow adds its own directory tosys.pathsohelpersand theactions/subpackage resolve correctly at runtime regardless of working directoryIntegration.load()now uses an explicit config path to avoid CWD-relative resolution issuesSDK 2.0.0 upgrade
requirements.txtbumped toautohive-integrations-sdk~=2.0.0config.jsonversion bumped to2.0.0response.dataaccesses updated acrosshelpers.py,actions/account.py,actions/media.py,actions/comments.py,actions/insights.pyTests
tests/context.pyandtests/test_instagram.py(SDK 1.0 style)tests/conftest.pyfor sys.path setuptests/test_instagram_unit.pywith 57 unit tests covering all actions, the connected account handler, helper functions, and error pathstests/test_instagram_integration.pywith live tests for all read actions plus a destructive comment lifecycle test (reply, hide, unhide, delete) gated behind@pytest.mark.destructiveTest plan
pytest instagram/tests/test_instagram_unit.pypasses 57/57pytest instagram/tests/test_instagram_integration.py -m integrationpasses with a validINSTAGRAM_ACCESS_TOKENpytest instagram/tests/test_instagram_integration.py -m "integration and destructive"passes to verify comment lifecycle