[DX-1015] Sync Control API spec with upstream swagger#3306
[DX-1015] Sync Control API spec with upstream swagger#3306kennethkalmer merged 1 commit intomainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughAn OpenAPI specification update that expands rule type variants (AWS Lambda, HTTP, Hive, text-moderation services), adds corresponding schema components, and updates namespace, app, key, and authentication-related schemas with new properties and type modifications. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
static/open-specs/control-v1.yaml (1)
7057-7099: Model APNs auth as mutually exclusive request shapes.Now that
apnsAuthTypeexists, these flat schemas still validate incomplete or mixed configurations—for example token auth without the p8 fields, or token and certificate fields together. AoneOfbetween certificate-based and token-based APNs configs would make the public contract much clearer for Redoc and codegen.Also applies to: 7134-7176
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@static/open-specs/control-v1.yaml` around lines 7057 - 7099, The APNs fields should be modeled as mutually exclusive shapes instead of flat optional fields: replace the current flat properties (apnsAuthType, apnsCertificate, apnsPrivateKey, apnsUseSandboxEndpoint, apnsAuthType, apnsSigningKey, apnsSigningKeyId, apnsIssuerKey, apnsTopicHeader) with a oneOf at the parent APNs config that defines two object schemas—a "certificate" schema (apnsAuthType: "certificate", required apnsCertificate and optionally apnsPrivateKey, apnsUseSandboxEndpoint, apnsTopicHeader) and a "token" schema (apnsAuthType: "token", required apnsSigningKey, apnsSigningKeyId, apnsIssuerKey and optionally apnsUseSandboxEndpoint, apnsTopicHeader); apply the same oneOf refactor to the other APNs block indicated (lines ~7134-7176) so codegen/Redoc will treat certificate vs token configs as exclusive.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@static/open-specs/control-v1.yaml`:
- Around line 5444-5470: The patch schemas hive_text_model_only_rule_patch,
bodyguard_text_moderation_rule_patch, tisane_text_moderation_rule_patch, and
azure_text_moderation_rule_patch currently enforce POST-style required fields
(ruleType, target, beforePublishConfig, invocationMode and apiKey inside
target); remove or relax these required entries so the schemas allow partial
PATCH bodies (e.g., only status or only target.thresholds). Specifically, edit
each schema to drop the top-level required array (or reduce it to match
http_rule_patch’s permissive pattern) and remove required entries inside target
(like apiKey) so partial updates validate correctly.
- Around line 4852-4853: The before_publish_aws_lambda_rule_patch schema
currently references rule_source making channelFilter and type required; change
its source $ref to refer to rule_source_patch (the patch variant with optional
fields) so partial updates are allowed—mirror what http_rule_patch and
kafka_rule_patch do by using rule_source_patch for
before_publish_aws_lambda_rule_patch.source to make fields optional.
- Around line 4980-4988: The response schema
before_publish_aws_lambda_rule_response currently references aws_access_keys
(which includes secretAccessKey) — change that $ref to aws_access_keys_response
to ensure secretAccessKey is omitted; similarly locate every moderation response
schema that currently exposes apiKey and replace or refactor them to use a
response-safe variant (e.g., api_key_response or remove apiKey) so raw API keys
are never present in responses; search for references to aws_access_keys and any
schema definitions that include apiKey in response schemas and update those
references to their _response-safe counterparts (or strip the sensitive field)
throughout the spec.
---
Nitpick comments:
In `@static/open-specs/control-v1.yaml`:
- Around line 7057-7099: The APNs fields should be modeled as mutually exclusive
shapes instead of flat optional fields: replace the current flat properties
(apnsAuthType, apnsCertificate, apnsPrivateKey, apnsUseSandboxEndpoint,
apnsAuthType, apnsSigningKey, apnsSigningKeyId, apnsIssuerKey, apnsTopicHeader)
with a oneOf at the parent APNs config that defines two object schemas—a
"certificate" schema (apnsAuthType: "certificate", required apnsCertificate and
optionally apnsPrivateKey, apnsUseSandboxEndpoint, apnsTopicHeader) and a
"token" schema (apnsAuthType: "token", required apnsSigningKey,
apnsSigningKeyId, apnsIssuerKey and optionally apnsUseSandboxEndpoint,
apnsTopicHeader); apply the same oneOf refactor to the other APNs block
indicated (lines ~7134-7176) so codegen/Redoc will treat certificate vs token
configs as exclusive.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: ad5e0e7c-c7a8-47e4-84dc-a9acceb86043
📒 Files selected for processing (1)
static/open-specs/control-v1.yaml
Bring the public Control API spec up to date with the upstream API surface. This was surfaced by a customer needing APNs p8 token-based auth fields (DX-1015). Additions: - APNs token auth fields (apnsAuthType, apnsSigningKey, apnsSigningKeyId, apnsIssuerKey, apnsTopicHeader) across app_post, app_patch, app_response - APNs/FCM config status fields in app_response - created/modified timestamps in app_response - revocableTokens in key_post, key_patch, key_response - mutableMessages and populateChannelRegistry in namespace schemas - appId in namespace_response - expires_at and token.id type fix in me schema - 7 new rule types (21 schemas): before-publish Lambda/webhook, Hive text/dashboard, Bodyguard, Tisane, Azure text moderation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
dd91174 to
4f7ea99
Compare
matt423
left a comment
There was a problem hiding this comment.
Me and Claudicus are satisfied
My heartfelt gratitude to you both |
Summary
app_post,app_patch, andapp_responseschemas — the immediate customer need from DX-1015created/modifiedtimestamps, and APNs config status booleans toapp_responserevocableTokensto key schemas,mutableMessages/populateChannelRegistryto namespace schemas,appIdtonamespace_responseme.token.idtype fromintegertostringand addsexpires_atfieldrule_post,rule_patch,rule_responsediscriminated unions with all new typesResolves DX-1015
Test plan
yamllintpasses — confirmed locally)yarn build) and verify Redoc renders the new fields correctly🤖 Generated with Claude Code
Summary by CodeRabbit