Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
haskell-gargantext
haskell-gargantext
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 159
    • Issues 159
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • gargantext
  • haskell-gargantexthaskell-gargantext
  • Merge Requests
  • !273

Merged
Opened Apr 08, 2024 by Alfredo Di Napoli@AlfredoDiNapoli
  • Report abuse
Report abuse

Introduce the `ToHumanFriendlyError` typeclass

Fixes #335 (closed).

Screenshot_2024-04-08_at_08.31.14

In order to fix this, I've introduce a new typeclass called ToHumanFriendlyError, and imposed a constraint over this class on the markFailure and markFailed methods of the MonadJob class, which means that programmers are now forced to think how the error they want to send out using the Job API will be rendered to the users.

This is important not only for a better user experience, but it also gives a chance to redact sensitive data: for example showing the raw Servant' ClientError to the user might be dangerous if some of these messages contained sensitive data like API Keys in the header response we would receive back.

Rather, the pattern should be that the raw message is logged using logLocM in the server logs (so that we can still audit them), but we need to show to users the "friendly" version.

Edited Apr 08, 2024 by Alfredo Di Napoli

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch origin
git checkout -b adinapoli/issue-335 origin/adinapoli/issue-335

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout origin/dev
git merge --no-ff adinapoli/issue-335

Step 4. Push the result of the merge to GitLab

git push origin dev

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

  • Discussion 0
  • Commits 1
  • Pipelines 1
  • Changes 12
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
1
Labels
Ready to merge
Assign labels
  • View project labels
Reference: gargantext/haskell-gargantext!273

Revert this commit

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this commit

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.