test(etcd): pin ProviderKey loader behavior for adapter-family payloads - #362
Conversation
Adds 4 unit tests in crates/aisix-etcd/src/loader.rs::tests:
✓ provider_key_happy_path_accepts — minimal valid pk shape
loads (the existing loader tests only covered Model + ApiKey
happy paths; provider_keys branch at L175 was unverified).
Three "documents current gap" tests for adapter-family extra
config that today fails to parse via `#[serde(deny_unknown_fields)]`
on ProviderKey:
✓ provider_key_aws_region_payload_currently_rejected — bedrock
✓ provider_key_gcp_project_payload_currently_rejected — vertex
✓ provider_key_azure_resource_payload_currently_rejected — azure
Each rejection test pins `stats.schema_rejected == 1`, so when
the ProviderKey struct gains adapter-family fields (or an
`adapter_config` escape hatch), each test will fail with
`accepted=1` instead of `schema_rejected=1`. That failure is the
correct signal — flip the assertion + drop the
`_currently_rejected` suffix in the same PR that adds the fields.
Filed the schema gap as #361. This unit-test PR
documents the contract; the product fix is tracked separately.
Tracking: api7/AISIX-Cloud#398 (Tier 3 MEDIUM "Pre-Patch #4 DP
loader schema check"), #361 (the actual struct fix).
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
Note 🎁 Summarized by CodeRabbit FreeYour organization has reached its limit of developer seats under the Pro Plan. For new users, CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please add seats to your subscription by visiting https://app.coderabbit.ai/login.If you believe this is a mistake and have available seats, please assign one to the pull request author through the subscription management page using the link above. Comment |
There was a problem hiding this comment.
Pull request overview
Adds targeted unit-test coverage in aisix-etcd for the provider_keys loader path, specifically pinning current acceptance/rejection behavior when ProviderKey payloads include adapter-family configuration fields (Bedrock/Vertex/Azure) that are not yet supported by the DP loader schema.
Changes:
- Added a happy-path unit test confirming a minimal valid
ProviderKeypayload is accepted and inserted into the snapshot. - Added three unit tests asserting that ProviderKey payloads containing
aws_region,gcp_project/gcp_region, andazure_resource_name/api_versionare currently schema-rejected (documenting the known gap to be fixed in #361).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // adapter_map.yaml:30, but the ProviderKey struct in | ||
| // `aisix-core::models::provider_key` is | ||
| // `#[serde(deny_unknown_fields)]` and has no `aws_region` | ||
| // field. Today the loader REJECTS the entry, so a customer | ||
| // creating a Bedrock provider_key via cp-api never sees | ||
| // the row reach the DP. Tracked as a follow-up to Adapter | ||
| // family e2e coverage (Tier 3 + Tier 4-7 in #398). |
| // `provider_keys` branch at L175 was unverified for either | ||
| // happy-path acceptance or for Adapter family extra-config | ||
| // rejection (the gap the audit on #398 originally flagged). |
Summary
Adds 4 unit tests in
crates/aisix-etcd/src/loader.rs::testscovering the ProviderKey loader path that was previously unverified:provider_key_happy_path_accepts..._aws_region_payload_currently_rejecteddeny_unknown_fields)..._gcp_project_payload_currently_rejected..._azure_resource_payload_currently_rejected100 LOC added, single file (existing test module extended).
Why
The audit on api7/AISIX-Cloud#398 flagged Adapter family bridges (Bedrock/Vertex/Azure, ~4986 lines of Rust) as zero-signal. This PR shows one of the underlying causes: even if someone wrote a Bedrock e2e tomorrow, the provider_key row carrying
aws_regionwould be rejected by the loader at DP boot time —#[serde(deny_unknown_fields)]onProviderKeyplus the absence ofaws_region/gcp_project/azure_resource_namefields means the row never reaches the snapshot.The three rejection tests pin the current behavior so when the product fix lands (filed as #361) the tests will fail with
accepted=1instead ofschema_rejected=1— that failure is the signal to flip the assertion + drop the_currently_rejectedsuffix.Test plan
cargo test -p aisix-etcd --lib loader::passes locally (16/16 including the 4 new ones)Tracking
api7/AISIX-Cloud#398 (Tier 3 MEDIUM "Pre-Patch #4 DP loader schema check")
#361 (the product fix that will make these tests evolve)