test(contract): prove the 402 envelope's current field against an over-cap account - #982
Open
AmirF194 wants to merge 2 commits into
Open
test(contract): prove the 402 envelope's current field against an over-cap account#982AmirF194 wants to merge 2 commits into
AmirF194 wants to merge 2 commits into
Conversation
…r-cap account account_limits_enforced asserts error.details.current, but at the moment of refusal current == limit by construction of the count >= cap checks in CheckAgentCreate/CheckDomainCreate, so a server that hardcoded Current to the cap would pass every existing assertion. Add a third seeded contract account (OverCapAPIKey) whose domains and agents are created before a lower cap is applied, so it starts already over both caps. A further create attempt is refused with current strictly greater than limit, which only a server reading the real resource count can produce. Verified by mutation: hardcoding Current to lim.MaxAgents / lim.MaxDomains fails the new scenario while account_limits_enforced stays green. Fixes tokencanopy#828 Signed-off-by: Amir Fathi <amirfathi.me@gmail.com>
…unners
The standalone contract-server helper (cmd/e2a-contract-server) wrote
E2A_TEST_BASE_URL, E2A_TEST_API_KEY and E2A_TEST_CAPPED_API_KEY to its
env file, but never E2A_TEST_OVERCAP_API_KEY, even though
testutil.ContractServer already exposes OverCapAPIKey. The Go
integration suite runs the contract server in process and reads
cs.OverCapAPIKey directly, so it never depended on that env var and
kept passing.
The TS and Python contract runners never read an
E2A_TEST_OVERCAP_API_KEY env var and never wired an overcap_api_key
template variable, so the new account_limits_current_field_proven
scenario's auth_override reached the wire as the literal string
"Bearer {overcap_api_key}". The server rejected that as an invalid
key with 401 before ever reaching the over-cap check, which is the
failure both jobs reported.
This adds E2A_TEST_OVERCAP_API_KEY to the env file the helper writes,
and wires it into both runners the same way E2A_TEST_CAPPED_API_KEY
already is, including a skip gate for a deployed target that has no
over-cap account to offer.
Verified in a clean Docker container against current HEAD: the Go
integration suite (go test -tags integration ./tests/contract/...)
passes all 33 scenarios including account_limits_current_field_proven,
the TypeScript contract suite passes 50 tests with 0 failures, and the
Python contract suite passes 48 tests with 0 failures.
Signed-off-by: Amir Fathi <amirfathi.me@gmail.com>
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
1 participant
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.
Summary
account_limits_enforcedassertserror.details.currentin the 402 envelope, but at the moment of refusalcurrent == limitby construction of thecount >= lim.MaxAgents/count >= lim.MaxDomainschecks ininternal/limits/enforcer.go. A server that hardcodedCurrentto the cap instead of the real resource count would pass every assertion in that scenario.This adds a third seeded contract account (
OverCapAPIKey) whose domains and agents are created before a lower cap is applied, so it starts already over both caps. A further create attempt is then refused withcurrentstrictly greater thanlimit, the only value a server actually reading the resource count can produce.Verified by mutation: I temporarily hardcoded
Current: lim.MaxAgents/Current: lim.MaxDomainsinenforcer.go.account_limits_enforcedstayed green; the newaccount_limits_current_field_provenscenario failed (error.details.current = 1, want 2), confirming it closes the gap.No production code changes:
CheckAgentCreate/CheckDomainCreatealready report the real count today, this only proves it and guards against a future regression.Client surface checklist
Test-only change, no API or client surface touched.
Operational risk
None. Test infrastructure only; no production code path changes.
Test plan
go test -tags integration -run TestScenarios ./tests/contract/...: new scenario passes; existingaccount_limits_enforcedstill passes.TestOverCapScenarioShape(new, mirrorsTestLimitsScenarioShape) pins the assertion shape.Currentto the cap inenforcer.gomakes the new scenario fail whileaccount_limits_enforcedstays green (reverted before pushing).make fmt-check,go vet -tags integration ./internal/testutil/... ./tests/contract/...,go build ./...all clean.make cover-checkcoverage-floor gate (needs the whole suite; my diff touches no package with a configured floor) and the TS/Python contract runners, which do not yet consumescenarios.yaml(per this file's own header comment).Fixes #828