Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Surface OpenRouter API errors as bounded enrich-set failure messages

Closed
#528 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
api, backend, cli

Research direction

Start by locating the OpenRouter client and the enrich-set workflow that currently turns non-200 responses into a generic error. Read tests/test_cli.py first to preserve its bounded-error contract, then trace the failed acquisition path and its durable attempt record. Done means 401, 403 key-limit, and 429 responses produce distinct bounded messages while failed work remains resumable.

Written by the indexing model from the issue text.

Description

draftomen enhancement size: S

Problem

When OpenRouter rejects a request (e.g. HTTP 403 key monthly limit exceeded), enrich-set fails with the generic 'Set-enrichment analysis failed.' The client maps every non-200 to a generic api code and discards the response body, so the operator cannot distinguish an exhausted key from a data bug. Reproduced during the HOB run of 2026-09-14: the run died at card 116 with no actionable message.

Proposed change

Map bounded, path-free API error classes (403 key limit, 401 auth, 429 rate limit) to explicit client error codes and include the code in the workflow error message. Keep the bounded-and-path-free CLI error contract (tests/test_cli.py pins that private causes are never printed).

Acceptance Criteria

  • AC1: A 403 key-limit response surfaces as an explicit bounded message naming the key limit, with no paths or private content
  • AC2: A 401/429 response surfaces their bounded classes distinctly
  • AC3: The bounded-error CLI contract test remains green and unmodified
  • AC4: A failed acquisition stays resumable; the failed work item keeps its durable attempt record

Dependencies

None

Implementation classification

  • Estimated size: S
  • Orchestration risk: Normal
  • Reason: Isolated error-mapping change in one client plus message threading.
Dominant language
Python
Stars
2
Forks
0
Avg merge
4h 48m
Merged PRs (30d)
225

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 andreagrandi/draftomen

All issues in andreagrandi/draftomen

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.