Flag Key Unique Constraint validation should not return 500

[marceloboeira]

The uniqueness constraint of flag.key is a known part of flag. Validation errors that rely on client-logic (uniqueness of a field) is responsibility of the client to implement, thus the server should return a 400-ish (e.g.: 400 Bad Request, 406 Not Acceptable, ...) and not a 500 Internal Server Error, since that is not the case.

Using httpie to exemplify:

http POST :18000/api/v1/flags Description=Sweden key=SE

HTTP/1.1 200 OK
Content-Type: application/json

{
    "dataRecordsEnabled": false,
    "description": "Sweden",
    "enabled": false,
    "id": 4,
    "key": "SE",
    "segments": [],
    "tags": [],
    "updatedAt": "2021-10-02T16:41:28.191Z",
    "variants": []
}

If you try that again, you should get something like...

Expected Behavior

http POST :18000/api/v1/flags Description=Sweden key=SE
HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "message": "cannot create flag. a flag with key=SE already exists"
}

But you end up getting a 500:

Current Behavior

http POST :18000/api/v1/flags Description=Sweden key=SE
HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
    "message": "cannot create flag. UNIQUE constraint failed: flags.key"
}

Possible Solution

Intercept this uniqueness constraint error and fail gracefully

Steps to Reproduce (for bugs)

See above...

Context

Semantically, validations errors should be client errors, 400-ish, since the server doesn't fail, yet the client fails on trying to bypass the uniqueness of the field.

Your Environment

• Version used (flagr version): 1.1.13
• Server type and version: docker/macOS Big Sur 11.6 (20G165)
• Operating System and version (uname -a): Helsinki.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

[github-actions[bot]]

Stale issue message

[pixeldrew]

@zhouzhuojie any word on this?

[github-actions[bot]]

Stale issue message

[bhasden]

Can someone educate me on the thoughts behind having a GitHub action to automatically close issues and pull-requests? Looking back through the closed items, there appears to be a lot of work done by volunteers which was seemingly ignored. I completely understand that people get busy and projects get stale, but having the issues and pull-requests stay open would give people who are: 1) evaluating the project and 2) considering forking the project, a better idea of the project state and what can be pulled into a fork of the project.