At a glance
| Input | Action | Output | Limit |
|---|---|---|---|
| Revoked permission | Stop protected source access | Permission-revoked state | Reauthorization occurs with the provider |
| Deleted or unavailable source | Preserve the source condition | Deleted or unavailable state | The app cannot restore the source |
| Rate limit or partial batch | Mark work deferred or partial | Retryable state where defined | A partial result is not complete coverage |
| Replayed source page | Match its prior identity | Replay state | Duplicate processing is not new evidence |
| GitHub terminology job | Preserve its terminal outcome | Reported, empty, failed, cancelled, or disabled | This workflow is report-only |
How it works
- Open Git Connector.
- Review Recent asynchronous jobs.
- Identify the exact job outcome.
- Check repository access and allowed paths.
- Resolve retryable causes before running another scan.
- Keep partial or unavailable evidence visible in downstream review.
Example
A GitHub scan loses repository permission after it is queued. The job does not appear as a clean result. Its failure remains separate from a scan that completed with no findings. Leadership can distinguish access loss from genuine zero-findings evidence.
What this does not mean
Failure contracts do not make every generic connector production-enabled. The current user-visible connector workflow is GitHub terminology checking. Public provider claims must match runtime wiring and the deployed manifest.
Related questions
Next step
Resolve the recorded cause before treating connector evidence as current.
View on Atlassian Marketplace