tiny-pilot / tiny-pilot/tinypilot

Have unified error code for all validation errors

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

Nobody has claimed this yet.

Dominant language
Python
Stars
3.5k
Forks
291
PR merge metrics
No merged PRs in 30d

Description

See POC in https://github.com/tiny-pilot/tinypilot-pro/pull/418.

In our dialogs, we display all validation errors in-place for the user to fix them right away. That’s different from how we handle operational errors, which should transition the dialog to the error state. Operational errors might have put the system in an inconsistent or unexpected state, so it’s then better to let the user start over.

Instead of assigning individual codes for the errors listed in request_parsers.errors, we can as well just put a general VALIDATION_ERROR code on the base class. The usual procedure of the frontend is to just dump the error message from the backend into the inline error component without further ado, so there is no actual need for distinguishing the individual validation cases. It’s also still possible to override the code if need be, but I’m pretty sure we’d get away with the general one.

I think that this makes error handling simpler for us, and more consistent. It also fixes a problem in the security dialog, where (unexpected) operational errors would be shown inline. That would otherwise require us to assign and check for additional error codes.

Contributor guide

Open the contributing guide

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

Start by locating the base validation error and request_parsers.errors, then compare the proposed behavior with the linked POC in tinypilot-pro pull request 418. Done means validation errors consistently expose VALIDATION_ERROR while operational errors remain distinguishable for the dialog error state.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Refactor
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.