Update OpenAPI spec#108
Conversation
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · ✅ LGTM
Updates the generated orchestrator OpenAPI mirror from rhinestonewtf/orchestrator@89e01d7, removing the stale x-feature-flags quote header from the contract.
Risk: Low - generated spec sync with a tiny header-only contract delta.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
4045500 to
523e670
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
Generated orchestrator spec provenance moved forward and the effective contract delta remains the tiny quote-header cleanup: x-feature-flags stays removed from the generated OpenAPI surface. No new schema issue found.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
523e670 to
cca528c
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
Generated orchestrator spec provenance advanced to rhinestonewtf/orchestrator@00ad6de, and the effective schema delta is still just the removal of the stale x-feature-flags quote header. No new contract issue found.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
cca528c to
3647ea5
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
Generated orchestrator spec now tracks rhinestonewtf/orchestrator@d500f94, adding vbUSDC/vbETH to the quote access-list and fee-token enums from the shared-configs bump; no new contract issue found.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
3647ea5 to
209a8fb
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
No effective orchestrator.json change since the last Greg review; the spec still contains the already-reviewed quote header cleanup and vbUSDC/vbETH enum additions.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
209a8fb to
4a0ed27
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
New head adds generated KEY_SCOPE_DENIED 403 schema coverage from the orchestrator provenance commit. Previous feedback had no unresolved items.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
4a0ed27 to
66dc706
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
New head only adds generated quote token enum coverage for USD, pathUSD, and USDC.e from the orchestrator shared-configs 1.6.4 sync. Previous feedback had no unresolved items.
![rhinestone-kevin[bot]](https://avatars.githubusercontent.com/u/127950714?s=60&v=4){kind=small}
| @@ -27,13 +27,6 @@ | |||
| "description": "API version (YYYY-MM.name). Will become required in a future release.", | |||
| "example": "2026-01.alps" | |||
| } | |||
| }, | |||
| { | |||
| "name": "x-feature-flags", | |||
There was a problem hiding this comment.
question — This removes the documented x-feature-flags header from POST /quotes; if existing consumers still use it to opt into gated quote behavior, regenerated clients will lose that contract. Is the orchestrator change intentionally retiring this header?
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
66dc706 to
28bfbf8
Compare
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
Direct orchestrator.json content is unchanged from the previous Greg-reviewed head 66dc706, despite the refreshed PR head/provenance commit. No new contract surface to review.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
28bfbf8 to
2b757ca
Compare
| @@ -1546,8 +1656,8 @@ | |||
| } | |||
| } | |||
| }, | |||
| "500": { | |||
| "description": "500", | |||
| "403": { | |||
There was a problem hiding this comment.
question — This new 403 response is described as API key scope denial, but its schema below still accepts VALIDATION_ERROR, INSUFFICIENT_LIQUIDITY, and the generic server/client error codes as valid 403 bodies. Is the intended 403 contract only KEY_SCOPE_DENIED, or should clients really treat every existing error shape as possible under this status?
greg-rhinestone
left a comment
greg-rhinestone
left a comment
There was a problem hiding this comment.
🤖 Greg · 🔄 Re-review · ✅ LGTM
Direct orchestrator.json content is unchanged from the previous Greg-reviewed head 28bfbf8, despite the refreshed provenance commit rhinestonewtf/orchestrator@b8427ad. No new contract surface to review.
Destiner
force-pushed
the
update/orchestrator-v1
branch
2 times, most recently
from
23cfe1b to
fa79077
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This same error union is still being added to every status-specific error response: here KEY_SCOPE_DENIED is accepted by the 400 schema, and the same shape also appears under the 403 and 500 schemas. Prior 403 thread asked whether scope denial should be the only 403 contract; if the answer is yes, generated clients should not also see scope denial as a valid 400 or 500 body.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
fa79077 to
f02b5dc
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same error shape is also present under the new 403 and 500 schemas; the prior 403/status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
f02b5dc to
4b3ab75
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses across the generated spec; the prior status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
4b3ab75 to
fe5dec7
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses; the prior status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
fe5dec7 to
242d425
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses; the prior status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
242d425 to
78922b3
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses; the prior status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
78922b3 to
01b56db
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — This still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses; the prior status-contract threads remain unresolved. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid 400 or 500 response.
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
01b56db to
8a082e3
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — The prior status-contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403, 500, and other status-specific responses. If scope denial is meant to be a 403-only contract, generated clients should not also treat it as a valid body for unrelated statuses.
…tor@da170a533d5ac418c334a3445f2c7da3acc3561a
Destiner
force-pushed
the
update/orchestrator-v1
branch
from
8a082e3 to
b34859f
Compare
| "code": { | ||
| "type": "string", | ||
| "enum": [ | ||
| "KEY_SCOPE_DENIED" |
There was a problem hiding this comment.
question — The prior status-specific error contract thread remains unresolved: this still adds KEY_SCOPE_DENIED to the 400 error schema while the same union also appears under 403 and 500 responses. If scope denial is meant to be a 403-only contract, generated clients should not treat it as a valid body for unrelated statuses.
2 participants
This PR updates the OpenAPI spec generated from rhinestonewtf/orchestrator@da170a533d5ac418c334a3445f2c7da3acc3561a.