Skip to content

fix: accept the API's error field as a string or an object - #8

Merged
catsika merged 1 commit into
mainfrom
fix/error-field-string-or-object
Nov 5, 2026
Merged

catsika merged 1 commit into
mainfrom
fix/error-field-string-or-object

Conversation

@catsika

@catsika catsika commented Nov 5, 2026

Copy link
Copy Markdown
Member

Keymint error responses carry error in two shapes: an object ({code, message, details}, e.g. rate limits and validation) and a plain string (e.g. the 405 "Method not allowed" and the IP-allowlist 403). Every error also has a top-level message and numeric code since keymint-codebase#227. KeyMintApiError.Error was typed as an object only, so a string body threw during deserialisation, and HandleResponse returned a generic HTTP error: ... Response: <raw body> with Code = -1 instead of the real message and code.

Change

  • New KeyMintApiErrorDetailsConverter on KeyMintApiError.Error. An object deserialises as before. A string becomes KeyMintApiErrorDetails { Message = "<string>" } (Code and Details stay null). null or a missing error gives Error == null.
  • The public types are unchanged. Callers that read result.Error.Error?.Message now also get the string form.
  • CHANGELOG: "Unreleased / Fixed" entry. No version bump.

Tests (Tests/ApiContractTests.cs)

  • Api_errors_accept_a_string_error_field: a 403 with a string error through ActivateKey returns the message, Code = 1 and Status = 403.
  • Api_error_field_deserializes_from_string_or_object: both shapes.
  • Api_error_without_error_field_deserializes: a missing error and "error": null.

Not run locally. This machine has no .NET SDK, so the build and contract tests rely on this PR's CI (dotnet test --filter "Category!=Live").

Some Keymint error responses send `error` as a string (405, IP-allowlist
403) and others as an object ({code, message}). KeyMintApiError typed it
as an object only, so string bodies failed to deserialise and callers got
a generic "HTTP error: ..." with Code = -1.

A JsonConverter on KeyMintApiError.Error reads either shape; a string is
kept in Error.Message.
@catsika
catsika merged commit 42fc492 into main Nov 5, 2026
2 checks passed
@catsika
catsika deleted the fix/error-field-string-or-object branch November 5, 2026 21:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant