feat(gateway): Complete OpenAPI 3.0 specification#40
Open
gilbertsahumada wants to merge 8 commits intoChaosChain:developfrom
Open
feat(gateway): Complete OpenAPI 3.0 specification#40gilbertsahumada wants to merge 8 commits intoChaosChain:developfrom
gilbertsahumada wants to merge 8 commits intoChaosChain:developfrom
Conversation
…lth check documentation
…ve admin path checks
11f962a to
d414f02
Compare
2 tasks
Contributor
|
@gilbertsahumada is this PR up to date? |
Contributor
Author
due to the latest updates, it's out of date. I'm going to merge the latest changes from the develop into my branch, push and it'll ready to be merged. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Builds on the existing
openapi.yamlto bring it up to full coverage of the Gateway API (27 endpoints). The original spec laid solid groundwork for the workflow endpoints; this PR extends it to cover the rest of the API surface and aligns a few field definitions with the latest code.Schema alignments
CreateWorkSubmissionRequest: updated to reflect the currentdkg_evidencefield (array ofDKGEvidencePackage) which replaced the earlierthread_root/evidence_rootfieldsCreateScoreSubmissionRequest: addedworker_addressandmodefields introduced with direct scoring supportWorkflowResponse.progress: expanded to document progress shapes for all three workflow typesWorkflowTypeenum: addedAgentRegistrationandStudioCreationHistoryEntry.role: updated toverifierto match the current return valuenullable: truewhere the code can return null:epoch,evidence_anchor,derivation_root,thread_root,studioPolicy,workMandateNew endpoint coverage
/v1/*public read endpoints: reputation, history, work, evidence, context, viewer, leaderboard, skills, PR ingestion/v1/sessions/*Engineering Studio session endpoints: create, append events, complete, context, evidence DAG, viewer/admin/*key management endpointsx-api-keyauth, admin authNew: OpenAPI sync test
Added
test/unit/openapi-sync.test.ts: a test that automatically detects drift between Express routes and the OpenAPI spec.This way, whenever someone adds or changes a route, the spec stays in sync without manual effort.
New: Gateway CI
Added
.github/workflows/gateway-ci.yml: runsbuild+teston every PR that touchespackages/gateway/.Validation
@redocly/cli lint: 0 errorsLooking ahead: single source of truth for validation + docs
The current validation layer uses hand-rolled functions (
validateAddress,validateBytes32, etc.) with TypeScriptascasts. This works, but it means the type definition, the validation logic, and the OpenAPI spec are maintained separately, which is what led to some of the fields drifting apart over time.A natural evolution would be migrating to Zod schemas, which unify all three into a single source of truth:
Benefits:
z.parse()catches invalid data with clear error messages@asteasolutions/zod-to-openapi, the spec can be derived directly from the schemasHappy to tackle this in a follow-up PR to keep this one focused on spec coverage. The migration is mechanical (interfaces -> Zod schemas, validate functions ->
.parse()) with no API-facing changes.