[management] Expect the rejection in the setup key integration tests

"Create Setup Key as on-off with more than one usage" asserted the old
behaviour directly: a key was created, and the response reported a usage
limit of 1 rather than the 3 that was asked for. That is the case this
change refuses, so the expectation becomes the rejection.

The case keeps its place in the table rather than being deleted, since it
is the one that says what happens when the request contradicts the key
type.
This commit is contained in:
mlsmaycon
2026-08-16 02:43:37 +00:00
parent aeeb9f9ee9
commit 6a82a39ced

View File

@@ -136,7 +136,10 @@ func Test_SetupKeys_Create(t *testing.T) {
},
},
{
name: "Create Setup Key as on-off with more than one usage",
// The key used to be created anyway, with its usage limit quietly
// reduced to 1, so the caller was told a key they had not asked for
// was what they asked for.
name: "Create Setup Key as one-off with more than one usage",
requestType: http.MethodPost,
requestPath: "/api/setup-keys",
requestBody: &api.CreateSetupKeyRequest{
@@ -146,23 +149,7 @@ func Test_SetupKeys_Create(t *testing.T) {
Type: "one-off",
UsageLimit: 3,
},
expectedStatus: http.StatusOK,
expectedResponse: &api.SetupKey{
AutoGroups: []string{},
Ephemeral: false,
Expires: time.Time{},
Id: "",
Key: "",
LastUsed: time.Time{},
Name: testing_tools.NewKeyName,
Revoked: false,
State: "valid",
Type: "one-off",
UpdatedAt: time.Now(),
UsageLimit: 1,
UsedTimes: 0,
Valid: true,
},
expectedStatus: http.StatusUnprocessableEntity,
},
{
name: "Create Setup Key with expiration in the past",