fix(source-nexus-datasets): add missing imports for AirbyteTracedException and FailureType#76138
Conversation
…ption and FailureType Co-Authored-By: bot_apk <apk@cognition.ai>
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. 💡 Show Tips and TricksPR Slash CommandsAirbyte Maintainers (that's you!) can execute the following slash commands on your PR:
📚 Show Repo GuidanceHelpful Resources
|
|
|
Deploy preview for airbyte-docs ready! ✅ Preview Built with commit 5d00445. |
Patrick Nilan (pnilan)
left a comment
There was a problem hiding this comment.
API Source PR Review
Connector: source-nexus-datasets
Connector Type: Low-code with custom components (manifest-only + components.py)
Linked Issue: https://github.com/airbytehq/airbyte-internal-issues/issues/16157
Verdict: APPROVED WITH CHANGES
The fix is correct and complete — adding the two missing imports for AirbyteTracedException and FailureType resolves the NameError on all error-handling paths. Tests are well-targeted and use the CDK fixture pattern correctly.
Two items to address before merge:
1. CDK version mismatch in unit tests
unit_tests/pyproject.toml pins airbyte-cdk = "6.10.0", but the runtime base image is source-declarative-manifest:7.10.0 (CDK 7.x). Tests should run against the same major version as production.
# Before
airbyte-cdk = "6.10.0"
# After
airbyte-cdk = ">=7.0.0,<8.0.0"2. Changelog placeholder PR number
docs/integrations/sources/nexus-datasets.md has [XXXXX] instead of the actual PR number:
# Before
| 0.1.4 | 2026-04-07 | [XXXXX](https://github.com/airbytehq/airbyte/pull/XXXXX) | ...
# After
| 0.1.4 | 2026-04-07 | [76138](https://github.com/airbytehq/airbyte/pull/76138) | ...|
CI checks are failing -- review, suggest fix, don't say "they're preexisting failures" |
|
Why are CI checks failing? |
…ype in FlexibleDecoder Co-Authored-By: bot_apk <apk@cognition.ai>
…x and fix changelog PR number Co-Authored-By: bot_apk <apk@cognition.ai>
|
Both review items addressed in commit 5d00445:
Additionally, the previous commit (76e4df0) fixed the CI |
What
Fixes missing imports for
AirbyteTracedExceptionandFailureTypeinsource-nexus-datasets/components.py. Without these imports, theFlexibleDecoder.decode()method raises aNameErrorat runtime instead of the intendedAirbyteTracedExceptionwhen encountering HTTP 304, 202, or other non-200 status codes.Also fixes a CI failure caused by the Nexus API returning
application/octet-streamcontent type for data exports, which the decoder did not previously accept.Resolves https://github.com/airbytehq/airbyte-internal-issues/issues/16157
How
from airbyte_cdk.models import FailureTypeimportfrom airbyte_cdk.utils.traced_exception import AirbyteTracedExceptionimportapplication/octet-streamto the accepted content types inFlexibleDecoder.decode()(the Nexus API uses this content type for JSONL data exports)conftest.py,pyproject.toml) and test file for this manifest-only connector>=7.0.0,<8.0.0to match the runtime base image (source-declarative-manifest:7.10.0)Review guide
components.py— two import additions (lines 17, 21) andapplication/octet-streamadded to accepted content types (line 196)unit_tests/test_components.py— 7 tests covering allFlexibleDecoder.decode()paths: error statuses, success, octet-stream, and unsupported content typeunit_tests/conftest.py— wires up the CDK'smanifest_only_fixturesfor component loadingunit_tests/pyproject.toml— test dependencies pinned to CDK 7.xmetadata.yaml— version bump to 0.1.4docs/integrations/sources/nexus-datasets.md— changelog entryapplication/octet-streamis a safe content type to accept as JSONL — the Nexus API returns it for data exports, but it is a generic binary type. Confirm this doesn't silently swallow non-JSONL binary responses.airbyte-cdk = "6.10.0"and[XXXXX]placeholder — both were fixed in the latest commit (5d00445). Verify they are correct on the branch head.User Impact
Connector error handling now works correctly. Previously, non-200 HTTP responses (304, 202, 5xx, etc.) would crash with an unhelpful
NameErrorinstead of surfacing the intended user-facing error message viaAirbyteTracedException. Additionally, successful data reads that returnedapplication/octet-streamcontent type would fail with aValueError— these are now decoded correctly.Can this PR be safely reverted and rolled back?
Link to Devin session: https://app.devin.ai/sessions/6c39a2e90977482a8601d2ee80e58292