fix: accept an attachment scalar as either a string or a number - #7
Merged
Conversation
#6 retyped `Attachment.Date` from int64 to string because ClickUp sends it as "1749381600000". Today the mirror image landed on the next field along: json: cannot unmarshal number into Go struct field Attachment.attachments.version of type string ClickUp is simply not consistent about which JSON scalar it uses here, and it can differ between the attachment endpoint and the copy embedded in a task response. Either Go scalar is therefore the wrong choice: whichever one is declared, some real response fails to unmarshal, and because the field sits inside every task payload the blast radius is `task get` AND `task update` for any task carrying an attachment -- the write applies server-side and still reports UNMARSHAL_ERROR, so a caller cannot tell it from a genuine failure. A queue-driven agent hit exactly that twice and both times spent the run on the CLI instead of the work. FlexString accepts both shapes and normalises to the string form, keeping the JSON output stable for consumers. It rejects anything that is not a scalar, so a real shape change still fails loudly rather than landing as "". Both fields use it; the regression test pins both shapes and the rejection. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#6retypedAttachment.Datefromint64tostringbecause ClickUp sends it as"1749381600000". Today the mirror image landed on the next field along:ClickUp is not consistent about which JSON scalar it uses here, and it can differ between the attachment endpoint and the copy embedded in a task response. Either Go scalar is therefore wrong: whichever is declared, some real response fails to unmarshal — and since the field sits inside every task payload, the blast radius is
task getandtask updatefor any task carrying an attachment. The write applies server-side and still returnsUNMARSHAL_ERROR, so a caller cannot tell it from a genuine failure.FlexStringaccepts both shapes and normalises to the string form, keeping JSON output stable for consumers. Anything that is not a scalar still fails loudly rather than landing as"". BothVersionandDateuse it; the regression test pins both shapes plus the rejection.go vetclean,internal/apigreen.cmd.TestParseSincefails onmaintoo (timezone-dependent, unrelated).🤖 Generated with Claude Code