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 179
    • Issues 179
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • 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
  • Issues
  • #502

Closed
Open
Opened Aug 25, 2025 by Alfredo Di Napoli@AlfredoDiNapoli
  • Report abuse
  • New issue
Report abuse New issue

`notifyJobFailed` should use `displayException`

While working on #498, I have found a small but significant ergonomic improvement we can make to notifyJobFailed. At the moment we have:

notifyJobFailed :: (HasWorkerBroker, HasCallStack)
                 => WorkerEnv
                 -> WState
                 -> BrokerMessage
                 -> SomeException
                 -> IO ()
notifyJobFailed env (W.State { name }) bm exc = do
  let mId = messageId bm
  let j = toA $ getMessage bm
  let job = W.job j
  withLogger (env ^. w_env_config . gc_logging) $ \ioL ->
    logMsg ioL ERROR $ "[notifyJobFailed] [" <> name <> " :: " <> show mId <> "] failed job: " <> show j <> "   --- ERROR: " <> show exc
  let ji = JobInfo { _ji_message_id = messageId bm
                   , _ji_mNode_id = getWorkerMNodeId job }
  let jh = WorkerJobHandle { _w_job_info = ji }
  runWorkerMonad env $ markFailed (Just $ UnsafeMkHumanFriendlyErrorText $ "Worker job failed: " <> show exc) jh

This is OK, but we are really getting the worst of both worlds by mixing UnsafeMkHumanFriendlyErrorText which, as the name implies, is for user friendly messages, and show, which is by Haskell98 standards an internal view on the datatype.

In my code, if we were to use the code as-is, we would get the following:

Screenshot_2025-08-25_at_10.45.48

This is hardly useful for the layman user.

Due to the fact that notifyJobFailed accepts any exception in the form of SomeException, we can't impose a ToHumanFriendlyError constraint on the function, but what we can do is to change the second show call this way:

notifyJobFailed :: (HasWorkerBroker, HasCallStack)
                 => WorkerEnv
                 -> WState
                 -> BrokerMessage
                 -> SomeException
                 -> IO ()
notifyJobFailed env (W.State { name }) bm exc = do
  let mId = messageId bm
  let j = toA $ getMessage bm
  let job = W.job j
  withLogger (env ^. w_env_config . gc_logging) $ \ioL ->
    logMsg ioL ERROR $ "[notifyJobFailed] [" <> name <> " :: " <> show mId <> "] failed job: " <> show j <> "   --- ERROR: " <> show exc
  let ji = JobInfo { _ji_message_id = messageId bm
                   , _ji_mNode_id = getWorkerMNodeId job }
  let jh = WorkerJobHandle { _w_job_info = ji }
  runWorkerMonad env $ markFailed (Just $ UnsafeMkHumanFriendlyErrorText $ T.pack $ displayException exc) jh

displayException is a method of the Exception class that has the exact purpose of showing a nice(r) message to users. Then, we can implement a proper displayException for things we care about, and at that point impose a ToHumanFriendlyError constraint.

I have implemented this exact approach as part of e05418f1 , as it's quite small so it makes sense to bundle it up with my work-in-progress feature.

As you can see, now the Exception instance for BackendInternalError demands an instance ToHumanFriendlyError BackendInternalError, and at the end of the chain we are able to pretty-print our "loop detected" error.

If we were to run that version of the code, we would see:

Screenshot_2025-08-25_at_10.43.19

Which is much nicer than the error above.

@cgenie Nothing actionable for you to worry about, I just wanted to show and validate the design with you, this is just a thing to be aware about, but I will add proper comments on the code to guide the developer towards the correct pattern.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
0
Labels
None
Assign labels
  • View project labels
Reference: gargantext/haskell-gargantext#502