OpenFn / OpenFn/lightning

Explain failed job errors to users

Open
#3,040 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Elixir
Stars
296
Forks
86
Avg merge
1d 13h
Merged PRs (30d)
50

Description

Goal:

  1. Make the debugging experience better and easier for users by showing/explaining error clearly

Metric:
NPS

Problem Observations:

  1. We have had reports of users not knowing what to do with errors don’t know what an error means e.g Killed or Crashed
  2. We have implemented clearer error messages in logs but it can still be difficult for users to see the error messages
  3. For a non-technical user, the logs can be verbose (even with the log filter) with error messages sandwiched

Image

Constraints:
Adding a drawer or a new panel tab to the inspector might be expensive. We might consider adding this to the new layout when the implemented

Assumptions:
We already have error messages in the logs and it might be easier to extract them into a panel that communicates the error in simple language.

Solution Concepts:

  • Final state based log filter
    Make the default log filter dependent on the job status. I should see an error when the job/step does not end in a successful state.

  • Add a “What is this?” button or icon to job errors
    This will show the error message in a drawer or tab and allow users to see/hide AI recommendations when available.

Image Image Image

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Review the existing job inspector and log experience, then clarify whether the selected scope is status-based log filtering, a “What is this?” error panel, or both; done should mean users can find and understand failed-job errors without scanning verbose logs.

Written by the indexing model from the issue text.

Assessment

Tech stack
elixir
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.