typed response decoding fails on real-world data — null `start_date`/`end_date` and object-valued idea `description`

[pauljwhite86]

Bug: typed response decoding fails on real-world data — null start_date/end_date and object-valued idea description

Repo: grokify/aha-go · Version: v0.4.0 (observed via grokify/aha-studio v0.8.0 MCP tools GetFeature/GetIdea/GetRelease/GetInitiative/ListIdeas)

Summary

Two struct field typings in the SDK don't match what the Aha! REST API actually returns, so Get*/List* calls fail to decode against live data:

1. Null dates — start_date (and end_date) are typed as non-nullable, but the API returns null when unset.
2. Idea description — typed as a string, but the API returns a rich-text object ({id, body, created_at, updated_at, attachments, ...}), the same shape used for feature/epic descriptions.

Affected calls

• Null date: GetFeature, GetRelease, GetInitiative
• Idea description: GetIdea, ListIdeas (and anything decoding an Idea)

Reproduction & errors

GetFeature("AI-25")
# decode FeatureResponse: ... decode field "start_date": unexpected byte 110 'n' at 320
#   (byte 110 = 'n' -> the literal null)

GetInitiative("AI-S-3")   # same: decode field "start_date": unexpected byte 'n'
GetRelease("AI-R-60")     # same: decode field "start_date": unexpected byte 'n'

GetIdea("AI-I-576")
# decode IdeaResponse: ... decode field "description": unexpected byte 123 '{' at 461
#   (byte 123 = '{' -> description is an object, not a string)

ListIdeas(...)            # same description '{' error

Root cause

• Date fields are declared as a value type (e.g. string/time.Time) instead of nullable, so a JSON null can't be decoded.
• Idea.Description is declared as string, but Aha! serializes it as the standard description object (same as Feature.Description/Epic.Description).

Suggested fix

• Make start_date/end_date (and any other optional date fields) nullable — e.g. *string / *time.Time (or a custom nullable date type), with omitempty.
• Change Idea.Description to the existing description object type used by other entities (the one carrying body, attachments, etc.) rather than string.

Workaround

Callers can route around these via the raw/REST path or search_documents, but the typed getters should decode live records directly.

[grokify]

Thanks for posting this.

This has been fixed in v0.9.0. Please try it.