GrottoCenter / grottocenter-api / 41695181394

91%

push

github

fix(document): answer 400 for an overlong title on creation (#1903)

## 🤔 What

- `POST /api/v1/documents` now checks the length of the strings it writes before opening the transaction: `title` (300), `creatorComment` (300), `identifier` (250), `issue` (100), `pages` (20) and `datePublication` (10).
- New `DocumentService.validateFieldLengths()` reads these limits from the `TDescription` and `TDocument` model definitions, so the check and the models cannot drift apart. It reuses the existing `api/utils/stringLengthValidation.js`.
- An overlong value gets a 400 with `{ message, errors }`. `errors` has one `{ field, message }` entry per overlong field, under its request field name, e.g. `title exceeds maximum length of 300 characters (got 622, 322 over limit).`
- `assets/swaggerV1.yaml` documents the `title` limit and the new 400 case.

Closes #1903

## 🤷‍♂️ Why

A title longer than 300 characters failed Waterline's validation (`E_INVALID_NEW_RECORD`) inside the create transaction. Nothing caught that error, so the API answered 500. Waterline's message also contained a meaningless "-322 characters longer" and should not reach users. The client should get a 400 that names the field and its limit.

## 🔍 How

- The controller calls `DocumentService.validateFieldLengths(documentData, descriptionData)` right after converting the body, next to the other pre-write checks. Nothing is created when it fails.
- When Waterline loads a model, it moves `maxLength` under `attributes.<name>.validations`, and the helper reads it from there.
- Only the create path is changed, as the issue asks. `PUT /documents/{id}` has the same limits and could reuse the helper in a follow-up.

## 🧪 Testing

- `test/integration/4_routes/Documents/create.test.js`: a 622-character title (the issue's payload) gets a 400 naming `title` and the 300-character limit, contains no negative number, and creates no description. A title of exactly 300 characters is accepted, and an overlong `creator... (continued)

6492 of 7540 branches covered (86.1%)

Branch coverage included in aggregate %.

8 of 8 new or added lines in 2 files covered. (100.0%)

11954 of 13013 relevant lines covered (91.86%)

233936.02 hits per line