Switch to a more robust solution that string matching for Catalyst error humanization

Open
#105 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Refactor
Clarity
Needs clarification
Activity status
Stale
Tech stack
go
Domain
backend

Research direction

Start by reviewing pull requests 101 and 104 to locate the current Catalyst error humanization and its string matching. Define how internal errors such as ErrInaccessibleFile should be categorized without exposing downstream implementation details, then verify that the resulting humanized messages remain stable across the listed underlying error messages.

Written by the indexing model from the issue text.

Description

https://github.com/livepeer/task-runner/pull/101 and https://github.com/livepeer/task-runner/pull/104 implemented humanized errors for certain internal errors. But, the approach is pretty fragile as it is based on string matching so if the error messages downstream change the logic here could break. We should consider a better way to categorize and transform these internal errors into humanized versions. For example, if there are special error types we could check if an error is of that type and determine the humanized error message to return i.e. ErrInaccessibleFile -> "file could not be accessed" and ErrInaccessibleFile could be used to wrap different error messages i.e. 504 Gateway Timeout, giving up after X attempts, etc.

This is scoped for Catalyst error humanization, but the approach here might be useful for other forms of error humanization as well.

Additionally, the string matching approach exposes task-runner to the internal details of Catalyst (i.e. MediaConvert). A better approach would hide those implementation details from task-runner.

Dominant language
Go
Stars
3
Forks
1
No merged PRs in 30d

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.

More from livepeer/task-runner

All issues in livepeer/task-runner

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.