Skip to content

Return Package processing errors back to the users

Problem to solve

RubyGems and NuGet packages are processed by a worker as they can't be processed in line with the upload request.

This worker may fail to process it due to various reasons:

  • invalid .gem file
  • invalid .gemspec file
  • invalide .nuspec file
  • Model level validations such as invalid version, name, etc...

In case of these errors, the worker will abort the current processing and delete the package file.

The issue is that all of this is completely hidden from the user. In other words, the user will not know that the processing ended up in an error. Packages that are still to be processed by the worker don't appear in the GitLab UI. So users could be waiting for nothing and that's a really bad UX.

Intended users

User experience goal

  • Users should have feedback on how the background processing with their RubyGems and NuGet packages went.

Proposal

  • Have a notification area about background processing events.

Design

image

This proposal might not be the best one. We could also go with the simple route:

  • Mail the user that uploaded the package with the errors.

Current workarounds

Users can use the API to filter and view packages that are being processed. We will also be adding the ability to filter by this param within the UI. If a gem is stuck in processing, they can then delete it and try again.

Permissions and Security

Only people allowed to upload RubyGems packages should be allowed to see those worker events / notifications.

Documentation

RubyGems docs are still in process, will update with the link after release. We'll need to do the same with NuGet packages.

What does success look like, and how can we measure that?

  • The number of RubyGems and NuGet worker notifications created.

What is the type of buyer?

  • This being an addition to the RubyGems repository and so they are bound to the tier where the RubyGems repository lives.

Is this a cross-stage feature?

  • There might be a generic/common way to notify the user: hey this happened.

Links / references

Edited by Tim Rizzi