Impact GateReference
Supported contracts and coverage
Prepare contracts for analysis and understand which evidence the current release can establish.
On this page
Supported inputs#
| Input | Current connected support | Important boundary |
|---|---|---|
| Provider API contracts | OpenAPI 3 documents in YAML or JSON | Documents need valid paths and resolvable local references; unsupported constructs leave gaps. |
| JavaScript / TypeScript consumers | Supported HTTP client patterns such as fetch and axios | Highly dynamic URLs, indirect runtime configuration, or unresolved wrappers may not be mapped. |
| Static API flows | Supported JS/TS and Java route handlers, function calls, consumer API reachability and downstream HTTP dependencies | Runtime traffic is optional. Unsupported languages, unresolved dispatch and incomplete source coverage remain explicit gaps. |
| Java consumers | Supported HTTP client patterns, including supported Spring clients | Framework support depends on recognizable source patterns; arbitrary reflection is not established. |
| Service identity | Repository roots and supported package / Spring / deployment manifests | Discovery may need review in monorepos or unusual layouts. |
| Runtime observations | Prometheus request counters and Datadog indexed APM spans | Requires an existing instrumented source, explicit service mapping, and fresh successful imports; missing data leaves usage unknown. |
| Optional model assistance | Planned*; not enabled | The connected worker currently performs deterministic analysis. No external model provider is connected, and model assistance is not required for the core analysis. |
Source-language support describes extraction capabilities, not complete support for every library or code pattern. Check repository Coverage and individual report notes for the actual result in your codebase.
Prepare a contract#
Commit the document
Keep the OpenAPI document in the selected provider repository on its default branch.
openapi.yaml,openapi.yml, or a JSON document containing theopenapifield are recognized examples.Use OpenAPI 3 and valid paths
Include an OpenAPI 3 version and a valid
pathsobject. Swagger 2 documents are not supported by the connected indexer.Bundle schema references
Use resolvable local references such as
#/components/schemas/Product. External references and unresolved references prevent a complete contract comparison.Describe the interface faithfully
Include request parameters, required fields, responses, media types, and relevant security requirements. Update this contract when the implementation changes.
Index and inspect
Save repository selection or choose Re-index. Open Coverage, then inspect the API and its schemas in APIs.
# Minimal illustrative provider contract.
openapi: 3.0.3
info:
title: Product API
version: 1.0.0
paths:
/v1/products/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: string
responses:
'200':
description: Product details
content:
application/json:
schema:
type: object
required: [id, priceCents]
properties:
id:
type: string
priceCents:
type: integerThis example illustrates document shape. Adapt it to your actual interface and normal contract validation process. Renaming the response field would change the contract, while a source-only rename without a matching contract update can leave drift unverified.
Examples of contract changes#
| Change | Why it needs review |
|---|---|
| Remove an endpoint or response field | A consumer may still request the endpoint or read the field. |
| Add a required request parameter or tighten a constraint | Previously accepted requests can become invalid. |
| Change a response type, media type, or success code | Parsing and status handling assumptions can change. |
| Remove an accepted request enum value | Existing clients may still send that value. |
| Add a response enum value | Consumers with exhaustive handling may not understand it. |
| Change descriptions or operation metadata | These usually do not alter the HTTP interface; review actual document differences. |
The report describes the detected change kind and its before/after values. The actual impact depends on consumer evidence and coverage; a breaking contract difference can be recorded even when no static caller was located.
Why coverage can be partial#
- No supported provider document was found, or a document was invalid.
- External or unresolved references prevented a complete contract comparison.
- A repository contains source languages or client patterns outside supported extraction.
- GitHub returned a truncated tree or an expected blob was unavailable.
- A file exceeded the per-file budget, contained binary data, or was a symlink.
- The repository or consumer analysis exceeded a processing budget.
Repository collection is size-bounded and focuses on API contracts and the code that uses them. Dependencies, build output, test directories, and lockfiles are left out. Very large repositories or files may be only partly covered, so the report lists what was and was not analyzed instead of promising exhaustive parsing.
Supported files, Skipped files, OpenAPI documents, and the notes under Coverage describe the saved result. Re-indexing can resolve a missing document or restored access, but it does not add support for an unsupported language.
What remains unknown#
- Implementation behavior or removed routes that are not reflected in the supported contract.
- Consumers outside selected, indexed repositories and clients maintained outside GitHub.
- Production traffic volume and caller inactivity without runtime observations.
- Deployment host associations for relationships inferred from endpoint paths.
- Highly dynamic or reflective calls that static extraction cannot resolve.
- Non-HTTP interfaces such as message queues, gRPC, and application-level WebSocket protocols.
- Downstream effects beyond the code and relationship evidence actually inspected.