Skip to content

feat(group): add rule-based HTTP contract mappings#703

Closed
JaysonAlbert wants to merge 4 commits into
abhigyanpatwari:mainfrom
JaysonAlbert:codex/group-http-manifest-links
Closed

feat(group): add rule-based HTTP contract mappings#703
JaysonAlbert wants to merge 4 commits into
abhigyanpatwari:mainfrom
JaysonAlbert:codex/group-http-manifest-links

Conversation

@JaysonAlbert

@JaysonAlbert JaysonAlbert commented Apr 7, 2026

Copy link
Copy Markdown
Contributor

Summary

Fixes #701.

This PR adds rule-based HTTP contract mappings for repository groups so frontend gateway URLs can be linked to backend service routes even when their paths do not literally match.

It also includes the request-like client support needed to make the flow work on real-world frontends that use wrappers such as request(...) / request.get(...) instead of plain fetch or axios.

What changed

Group-level HTTP mappings

  • add http_mappings to group.yaml
  • support:
    • source repo selection via from
    • target repo and optional service boundary via to.repo / to.service
    • optional method filtering via methods
    • declarative path matching via match
    • optional param constraints via when
    • path rewriting via rewrite
  • use path-to-regexp for matching, param extraction, and path generation
  • rewrite matched frontend consumer contracts into canonical backend contract IDs before exact matching
  • emit cross-links with matchType: manifest

Group YAML persistence

  • keep group.yaml as a snake_case configuration format
  • serialize internal httpMappings back to http_mappings when group add / group remove rewrite the file
  • avoid leaking internal camelCase field names into persisted YAML

Cross-link bookkeeping

  • extend cross-links with fromContractId / toContractId
  • update unmatched contract filtering so rewritten manifest links still mark both endpoints as matched

Request-like frontend HTTP consumers

  • recognize imported request-like clients in ingestion, including:
    • request('/api/...')
    • request('/api/...', { method: 'POST' })
    • request.get('/api/...')
    • request.post('/api/...')
  • avoid misclassifying those calls as Express route registrations
  • add equivalent request-like support to HttpRouteExtractor source-scan fallback so group sync can still extract HTTP consumers even when no FETCHES graph edges are present

Why this shape

A per-endpoint manifest link model is too heavy for enterprise setups where frontend traffic goes through a gateway namespace such as:

  • /api/titans/<service>/<version>/...

and backend services expose internal routes such as:

  • /tradeflow/...
  • /margin/...
  • /orders/...

With rule-based mappings, one service-level rule can cover many endpoints while keeping matching deterministic and auditable.

The YAML-format fix is intentionally strict: group.yaml is treated as a user-facing config surface, so the persisted format should stay stable and explicit rather than drifting toward internal TypeScript field names.

Validation

Ran:

cd gitnexus && npx tsc --noEmit
cd gitnexus && npm test -- test/unit/call-processor.test.ts test/integration/resolvers/express-routes.test.ts
cd gitnexus && npm test -- test/unit/group/config-parser.test.ts test/unit/group/http-route-extractor.test.ts test/unit/group/sync.test.ts test/unit/group/service.test.ts test/unit/group/types.test.ts test/integration/group/group-sync.test.ts

I also validated this against a real libra-client + libra-server + libra-trading group locally:

  • before: 0 HTTP cross-links
  • after adding http_mappings and request-like consumer extraction: 407 manifest cross-links
  • trading paths now link into backend/libra-trading as well

Notes

  • existing links behavior is preserved
  • no mappings means existing behavior is unchanged
  • this PR depends only on declarative configuration and does not try to infer gateway rewrite rules automatically
  • group.yaml's persisted mapping key is http_mappings
  • request-like handling overlaps with the narrower bugfix in bug(ingestion): request.get/post client calls can be misclassified as Express routes #692 because the end-to-end group-sync scenario depends on frontend consumers being classified correctly

@vercel

vercel Bot commented Apr 7, 2026

Copy link
Copy Markdown

Someone is attempting to deploy a commit to the NexusCore Team on Vercel.

A member of the Team first needs to authorize it.

@magyargergo

Copy link
Copy Markdown
Collaborator

I believe we have already tackled with this task, right @ivkond ? Your PRs are handling this case? If so please close this PR and the releated issue.

@magyargergo

Copy link
Copy Markdown
Collaborator

Please submit a new PR if this is still relevant

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

feat(group): support HTTP contract linking when gateway paths differ from backend routes

2 participants