Update snippetBlob point for handling rendering errors of blobs

After discussions on the matter of handling the rendering errors of blobs in snippets, it has been agreed that SnippetBlob end point in GraphQL should be extended to at least contain:

  • external_storage, and
  • rendered_as_text?

for the frontend to be able to construct corresponding error messages. The parameters list above might be not extensive so it's up to backend to decide on the exact params to include in the blob definition.

Original Description (for historic background)

In the course of handling some specific rendering issues of the blobs like too large blob or too many lines (collapsed), etc a need for an update of the GraphQL endpoint emerged.

At the moment, a viewer object returns something like this:

"simpleViewer": {
  "collapsed": true,
  "renderError": "collapsed",
  "tooLarge": false,
  "type": "simple",
  "fileType": "text"
},

As one can see, the renderError doesn't return any useful information here.

This has been discussed with @fjsanpedro over a Zoom call and here is what we came up with as a plan for pushing handling this type of errors in GraphQL and unblock (#216453 (closed)) further:

  1. "renderError" should return a real message built and formated based on app/views/projects/blob/_render_error.html.haml

⚠ This Issue's scope is limited with ☝ task.

More details on the overall implementation

However, there's a need to provide some more details for the full picture of the implementation. The solution above will work with one exception. The "load it anyway" link:

Too large file

that is supposed to render the blob's content if that's what user needs will be returned such that clicking it will reload the page with a special parameter in URL (expanded=true). This works for a single-file scenario but will fail in the multi-file snippets (a WIP at the time of writing) as there's no information about what snippet to expand. Hence, we have agreed on additional steps:

  1. In case collapsed: true for the viewer, frontend should process the renderError and make sure we do not re-load the page when the "load anyway" link is clicked, but instead, we make another GraphQL call (already existing) to fetch content for this particular blob and inject it "right here, right now" without page reload. This essentially re-defines the scope for #216453 (closed).

Why not updating ruby code driving app/views/projects/blob/_render_error.html.haml instead?

Technically, after Snippet view has been refactored to Vue we do not use that template at all and would ideally need to move all of its functionality into Vue app. However, it would also require extending current GraphQL implementation with quite a few additional information bits that might not be the most optimized and practical way atm.

Also, because this template is shared between all instances of the blobs (like File in repository, for example) and it can not be changed without consequences in all instances of the blobs.

/cc @fjsanpedro @dsatcher @rkuba

Edited by 🤖 GitLab Bot 🤖