speakeasy-api / speakeasy-api/kit
Preserve sanitized upstream provider classification in fatal records
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 40
- Forks
- 4
- Avg merge
- 4h 18m
- Merged PRs (30d)
- 148
Description
Summary
When an openai-subscription retry budget is exhausted, the parent-visible error can retain a sanitized upstream classification such as service_unavailable_error/server_is_overloaded, but the schema-v2 fatal record collapses it to a generic retry_exhausted or response_failed classification.
Split from #35 after the underlying overload retry behavior was fixed by #32.
Current behavior
Fatal classification prioritizes the local exhaustion category and stores a generic message. The sanitized upstream type/code that explains why retries occurred is not retained as structured fatal data. This makes the on-disk diagnostic less useful than the transient provider classification already available earlier in the error path.
Desired behavior
Preserve both layers in fatal diagnostics:
- local terminal category, for example
retry_exhausted; and - sanitized upstream provider type/code, for example
service_unavailable_error/server_is_overloaded.
Do not store the raw provider response, provider message text, prompts, headers, credentials, or other sensitive payload data. Keep field lengths bounded and classifications canonical.
Suggested coverage
- Exhaust retries after
service_unavailable_error/server_is_overloadedand assert both local and upstream classifications. - Assert unknown transient spellings remain bounded and sanitized.
- Assert raw provider bodies and sensitive message text never enter schema-v2 fatal JSON.
- Preserve compatibility for readers of existing fatal records when the persistent schema changes.
Environment
- Originally observed with Kit
0.1.96onDarwin 25.6.0 arm64. - Confirmed as a remaining gap on Kit
0.1.105onDarwin 25.5.0 arm64. - Surface: ACP; provider route:
openai-subscription.
Related work
- #35
- #32
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the schema-v2 fatal-record handling for the ACP openai-subscription retry-exhaustion path, then trace how the sanitized provider type and code are available before the fatal record is written. Add coverage for preserving both classifications, bounded sanitization, and exclusion of raw bodies or sensitive text; verify compatibility with existing fatal records.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100