Azure / Azure/data-api-builder

Allow custom exceptions in production mode

Offen
#2,222 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
enhancement usability
Vorherrschende Sprache
C#
Sterne
1.5k
Forks
370
Ø Merge
3 T. 22 Std.
Gemergte PRs (30 T.)
9

Beschreibung

As a user of API's myself I really appreciate helpful messages explaining why the action failed. It really helps with development and maintenance. If a user complains an action hasn't worked, the error message can really help save a lot of time debugging.

Currently with DAB if an error is thrown by a stored procedure it will only be displayed in development mode only. [Code](https://github.com/Azure/data-api-builder/blob/f996f10553096e389a2421abe0a98f0327d4435e/src/Core/Resolvers/DbExceptionParser.cs#L44C13-L44C88)

However I would like to display certain custom error messages to users of the API even in production mode.

Some examples I have in my SP's:

- Duplicate Email Address, contacts must have unique email addresses.
- ManagerId does not exist
- LastName cannot be blank
- FromDate is greater than last update of messages 2024-05-01
- Invalid NominalCode for the Chart of Accounts
- ManagerId does not have permission to access this client

Currently there are the following exception types for MsSql although it's similar for the other parsers: [Code](https://github.com/Azure/data-api-builder/blob/main/src/Core/Resolvers/MsSqlDbExceptionParser.cs)

- BadRequestExceptionCodes
- TransientExceptionCodes
- ConflictExceptionCodes

From the Code link, it's visible there is a hard coded list of exception code numbers which relate to each type.

Why not add in **UserExceptionCodes**?
Then make an exception for those codes to keep the real error message.

Then we can simply add something like the below to return an error to the user of the API.

THROW 60001, 'LastName cannot be blank', 1;

Options to implement this:
1. This could be error codes with a number >50000 in the case of MsSql (as these are kept for user exceptions).
2. Hard code a small range of codes we can use, e.g. 60000-61000.
3. Add this as an option to the configuration file to specify a range of codes to be used for user exceptions.

Beitragsleitfaden

Beitragsleitfaden öffnen

Rechercherichtung

Beginnen Sie mit src/Core/Resolvers/DbExceptionParser.cs und vergleichen Sie die anbieterspezifische Verarbeitung in src/Core/Resolvers/MsSqlDbExceptionParser.cs, insbesondere die vorhandenen Gruppen von Exception-Codes. Ermitteln Sie, wie ein Bereich für User-Exception-Codes oder eine Konfigurationsoption ausgewählte Stored-Procedure-Meldungen in production beibehalten sollte, während die aktuelle Verarbeitung für andere Codes erhalten bleibt; als abgeschlossen gilt dies, wenn das Verhalten und die gewählte Konfiguration über die relevanten Parser hinweg konsistent definiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
csharp, sql
Bereich
api, backend-api-design, databases
Issue-Typ
Feature
Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Aktivitätsstatus
Veraltet
Klarheit
Größtenteils klar
Anfängerfreundlichkeit
35/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.