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 154
    • Issues 154
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 7
    • Merge Requests 7
  • 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
  • !219

Merged
Opened Oct 31, 2023 by Alfredo Di Napoli@AlfredoDiNapoli
  • Report abuse
Report abuse

Frontend error refactoring

Eventually fixes #267 (closed). This is a work in progress preview of the work I'm doing on the refactoring of the error format, to make it consistent with the frontend. I have explored various designs, but I have settled on the following:

  • We have a top-level type called FrontendError, which is opaque and captures two things: the BackendErrorCode, which is a "tag" uniquely identifying the particular error code that the server is emitting, and a specific payload which depends on the given BackendErrorCode. The relationship between a BackendErrorCode and its associated payload is bijective, i.e. there is a 1:1 mapping between the two. This makes for a slightly more verbose internals but the advantage is that we can be very precise in shaping the associated frontend error given a backend error.

Apart from this, I have now renamed the old GargError to be called BackendInternalError, and the idea is that throughout the backend server we throw internal backend errors and then at "the boundaries" (i.e. close to the application surface) we perform the conversion between a BackendInternalError and a FrontendError. We don't have to do this ourselves: this is done automatically as part of the backendErrorToFrontendError function which is currently WIP (we have a bunch of undefined there).

Last but not least, in the Main code that turns a Servant server into a WAI Application we will eventually call frontendErrorToServerError, which is responsible to generate a suitable ServerError (<- the servant type) which will render nicely and consistently on the frontend side.

The idea is that now the frontend will always have a valid BackendErrorCode tag returned in the error, and parsers can be written to process incoming JSON solely based on this tag.

What's remaining for this MR to become ready:

  1. ✅ We need to fix all the undefined;
  2. We need to replace all the panic and error we throw in the handlers with proper BackendInternalError;
  3. Switch the main loop to call frontendErrorToServerError.

To be continued on Thursday and next week.

Edited Nov 07, 2023 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-267 origin/adinapoli/issue-267

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-267

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 3
  • Commits 19
  • Pipelines 11
  • Changes 65
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
0
Labels
None
Assign labels
  • View project labels
Reference: gargantext/haskell-gargantext!219

Revert this merge request

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 merge request

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