---
name: hydra-sentry-high-confidence-clusters
description: Reference rubric for ad hoc analysis of Hydra-generated Sentry connector fixes; classifies high-confidence candidate clusters, exclusions, and proof signals without enabling workflow automation.
devin-enabled: false
icon: merge
---

# Hydra Sentry High-Confidence Clusters

Use this reference when answering ad hoc questions about whether a Hydra-generated PR that fixes an Airbyte Sentry issue resembles a narrow, low-risk, high-confidence issue class.

This skill is **documentation only**. It is not part of the regular Hydra workflow, does not enable auto-merge or any action, and should not be used as an operational gate until the rubric has been refined and explicitly adopted by an approved workflow change.

Never merge a PR unless the user or an approved automation policy explicitly authorizes the merge.

## Output

For every issue or PR evaluated, produce this classification:

```text
Cluster: <HYDRA-SENTRY-A | HYDRA-SENTRY-B | EXCLUDED>
Tier: <Tier 1 | Tier 2 | Tier 3>
Decision: <high-confidence candidate | human review required | not eligible>
Reason: <one concise sentence>
Evidence:
- <PR/issue/proof signal>
- <PR/issue/proof signal>
Missing proof:
- <none, or exact missing requirement>
```

## Cluster HYDRA-SENTRY-A: Declarative connector error-handling patches

This cluster covers connector-local declarative manifest changes that handle a known non-fatal upstream API response.

### Inclusion rules

The PR must satisfy all of these:

1. The fix is scoped to one connector.
2. The functional change is declarative manifest YAML, plus tests, connector version bump, and changelog when required.
3. The core behavior is an exact `HttpResponseFilter`, `action: IGNORE`, or equivalent bounded declarative error-handling rule.
4. The predicate matches a specific API response code, upstream error code, upstream error type, stream, or exact message substring.
5. The skipped or ignored response is explicitly safe because it is one of:
   - Deleted or missing resource.
   - Unsupported metric, field, or report for that account.
   - Bounded invalid time slice or parameter that will be retried or become valid later.
   - Non-fatal per-record or per-slice upstream behavior.
6. No stream schema, spec, auth, stream list, primary key, cursor, or state behavior changes.
7. Required CI checks pass.
8. Regression or live proof covers `spec`, `check`, `discover`, and `read`, or the proof directly exercises the exact ignored response path.
9. The PR or proof explains why ignoring the response is safe and will not hide data loss.

### Common examples

- Chargebee subscription `404` resource-not-found ignored for a bounded stream response.
- Instagram future `since` parameter error ignored for a future slice.
- Klaviyo unsupported conversion metrics ignored when the API says the metric is unsupported.
- Zendesk declarative pagination accessor narrowed to handle a missing optional response field.

### Reference decision

Classify as `Tier 1` and `high-confidence candidate` for analysis purposes only if every inclusion rule passes and no hard exclusion applies.

If the issue looks like this cluster from Sentry text but the PR changes Python retry logic, parser behavior, cursor behavior, or broad error classification, classify it as `EXCLUDED`.

## Cluster HYDRA-SENTRY-B: Connector-local defensive guard or normalization patches

This cluster covers small connector-local Python fixes that prevent a known unhandled exception without changing intended sync semantics.

### Inclusion rules

The PR must satisfy all of these:

1. The fix is scoped to one connector.
2. The functional diff is small and localized to the failing branch from the Sentry traceback.
3. The change is a guard or normalization for an unexpected but non-semantic value shape, such as:
   - `None` response object.
   - `None` logger or handler state.
   - Missing optional response field.
   - String value where numeric comparison is intended.
   - Alternate timestamp or scalar representation with the same semantics.
4. The fix preserves existing intended behavior, such as continuing an existing handler, surfacing the existing error, or applying the same comparison after type normalization.
5. A targeted unit or mock test reproduces the exact exception before the fix and passes after it.
6. Required CI checks pass.
7. Connector regression tests pass, or the proof explains why the branch is unit-local and direct unit proof is stronger than network regression coverage.
8. No broad exception catch, generic fallback, retry loop, auth behavior, schema/spec/state/cursor behavior, stream selection, or dependency change.

### Common examples

- Shopify guard for `logger=None` in local error handling.
- GitHub guard for request exception where `response` is `None`.
- Facebook Marketing guard for `api_error_message=None`.
- Facebook Marketing normalization of throttle header values from strings to floats before comparison.

### Reference decision

Classify as `Tier 1` and `high-confidence candidate` for analysis purposes only if every inclusion rule passes and no hard exclusion applies.

Parser normalization is eligible only when tests cover both the old and new representations and the normalized value has the same domain meaning.

## Hard exclusions

Classify as `EXCLUDED` and require human review if any of these are true:

1. Shared CDK, platform, framework, or auth behavior changes.
2. More than one independent bug is fixed.
3. Retry, backoff, cursor, state, checkpoint, slicing, pagination strategy, or date-window semantics change.
4. Stream schema, spec, primary key, stream list, sync mode, or configured catalog behavior changes.
5. Destination connector write behavior changes.
6. Java/Kotlin connector runtime behavior changes, unless a future policy explicitly covers that stack.
7. The fix changes user-facing error classification or `FailureType`, unless it is message-only, deterministic, connector-local, tested, and follows Airbyte error-message guidelines.
8. The PR adds broad `except`, catch-all fallback, silent data skipping, or generic suppression.
9. The proof is blocked, partial, inconclusive, missing, or says the fix is only "no worse".
10. Required CI checks fail or are pending at decision time.
11. The PR is draft, conflicted, stale, or not mergeable.
12. A human requested code or design changes.
13. A bot raised a substantive correctness or security concern that has not been resolved.
14. The PR depends on an unapproved version pin, customer live test, or customer-specific assumption.
15. The root cause is ambiguous or inferred only from logs without direct reproduction.
16. The fix could hide data loss and the proof does not explicitly bound the skipped data.

## Tier definitions

### Tier 1: High-confidence candidate

Only Cluster HYDRA-SENTRY-A or HYDRA-SENTRY-B can be Tier 1.

Required evidence:

- Direct Sentry traceback or upstream API response matched.
- Targeted regression, unit, mock, or live proof covers the failing path.
- Required CI checks pass.
- No hard exclusion applies.

### Tier 2: Human review recommended

Use Tier 2 when the shape resembles a safe cluster but one confidence input is missing or weaker than required.

Examples:

- Regression passed but no targeted before/after test exists.
- The fix is connector-local but parser semantics are slightly ambiguous.
- The PR is safe-looking but proof does not cover the exact Sentry path.

### Tier 3: Not a high-confidence candidate

Use Tier 3 when any hard exclusion applies or the fix is outside the two high-confidence clusters.

Examples:

- Shared CDK/auth changes.
- Retry, cursor, state, or slicing changes.
- Multi-bug combined fixes.
- Draft or conflicted PRs.
- Inconclusive proof.

## LLM classification prompt

Use this prompt when asking an LLM or agent to classify a future issue or PR:

```text
Classify this Hydra-generated Airbyte Sentry fix using the hydra-sentry-high-confidence-clusters rubric.

Inputs:
- Sentry/oncall issue:
- PR:
- Diff summary:
- Test and proof results:
- PR comments/review signals:

Return exactly:
Cluster: HYDRA-SENTRY-A, HYDRA-SENTRY-B, or EXCLUDED
Tier: Tier 1, Tier 2, or Tier 3
Decision: high-confidence candidate, human review required, or not eligible
Reason: one sentence
Evidence: bullets
Missing proof: bullets

Apply hard exclusions before assigning Tier 1.
If any required evidence is unavailable, do not classify as a high-confidence candidate.
```

## Notes for future refinement

- This rubric is intentionally conservative. It identifies high-confidence candidate clusters for ad hoc analysis; it does not replace CI, regression testing, or proof-of-fix validation.
- Treat Sentry title/body matching as a pre-filter only. Final classification must inspect the PR diff and proof results.
- Keep examples updated as future Hydra PRs succeed or fail. Add negative examples whenever a superficially safe PR required human design changes.
- Do not wire this rubric into the regular Hydra workflow, auto-merge, or any action until the classification has been reviewed, refined, and approved as an explicit workflow change.
