AtomPipeline mixes parse- and render-time concerns, and shouldn't exist
Source: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228411#note_3188971676 > My reasoning is, the `AtomPipeline` kind of makes no sense to begin with: the Banzai system has us declare pipelines on a per-_field_ basis (`cache_markdown_field :note, pipeline: :note`, for example), and then use `markdown_field` to automatically render using the right pipeline, cache the output in the database, and then use that cached version when possible. Overriding the pipeline on a per-_view_ (or serialisation type) basis doesn't quite make sense, is a possible security issue, and can't make use of the cached render. It's used in exactly three places AFAICT (`app/views/events/_event_{issue,merge_request,push}.atom.haml`), so this should be easy to remove. The correct way to get the desired result is currently obscure, depending on calling a side-effectful method which populates some cache fields, which then get read by `markdown_field`: we should refactor this out and make it easier to take an existing field render, whether it's rendered just-in-time or pulled from cache, and present it for Atom(/XHTML) when needed.
issue