Description
Use the POST HTTP request method to create the Metrics Platform Instrument Configurator application.
- POST /instrument
- Validate the double-submit cookie. If the double-submit cookie is invalid, then clear the session cookie and redirect to GET /. Otherwise, continue processing the request.
- Validate the form. If the form invalid, then show the form with validation errors and stop processing and, since the form is state-changing, send a fresh double-submit cookie with the response. Otherwise, continue processing the request.
- Insert the corresponding rows into the instrument and instrument_sample_rate tables above.
- If the insertion fails, then show the form with an error message and stop processing and, since the form is state-changing, send a fresh double-submit cookie with the response. Otherwise, continue processing the request.
- Add an entry to the SAL for the current day. If adding an entry fails, then log the failure and continue processing the request.
- Authentication/authorization is required.
Use Case
The POST HTTP request method will be used by the frontend application aka Metrics Platform Instrument Configurator (MPIC) to create data.
User Story/ies
As an engineer, I'd like to send a POST request to the MPIC endpoint to create an instrument's configuration.
Outcome
Submitting a POST HTTP request to the MPIC post endpoint inserts rows in the instrument and instrument_sample_rate tables as noted in the data models of the design document.
Acceptance Criteria
- The POST endpoint is able to create instrument configuration.
- Double-submit cookie is validated.
- Form validation of post data.
- Graceful failure of invalid data, non-200 responses.
- Logging success/errors to SAL
Required
- Unit/Integration tests
- Testing Instructions
- Documentation
- Passed QA
Technical Notes
- About how to log instrumen registration to SAL:
@cming@wikimedia.org @Sfaci@wikimedia.org Be aware that there may be a need to abstract away precisely how we're logging to the SAL (or "deployment-like" events). > For now, it might do to just put the SAL-updating logic behind an interface so that it can be varied later, e.g.
interface DeploymentLogger {
async logDeployment( instrumentName, message ): void;
}
Dependencies
- We can stub responses during development - once the datastore is active, data should be inserted into there instead.