fix: accept a custom-field create response with no object field - #41
Merged
Merged
Conversation
POST /v1/custom-fields omits `object` from the fields it echoes back, though GET includes it and the API reference documents it on both. CustomFieldSchema requires it, so a successful create threw AssemblyResponseParseError *after* the field existed — and the API has no delete for custom fields, so retrying left an undeletable duplicate behind. The create response now parses through CreatedCustomFieldSchema, where `object` is optional. CustomFieldSchema keeps requiring it so list responses don't lose the guarantee. Revert both once the API sends the field. 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.
POST /v1/custom-fieldsomitsobjectfrom the fields it echoes back, thoughGETincludes it and the API reference documents it on both.CustomFieldSchemarequires it, so a successful create threwAssemblyResponseParseErrorafter the field existed.That's a bad failure mode for this endpoint in particular: the API has no delete for custom fields, so a caller who sees the throw and retries ends up with an undeletable duplicate. Hit for real while creating company-level fields for OUT-4090.
Actual response body, verbatim:
{"customFields":[{"id":"388ac3ed-dbb3-45c4-823d-3f847a35f706","key":"propertyType", "name":"Property Type","type":"multiSelect","order":3, "options":[{"id":"option-8dfa39d0-…","key":"hotel","label":"Hotel","color":"rgba(144, 149, 157, 1)"}], "entityType":"company"}]}What to look at
src/lib/modules/custom-fields/schema.ts—objectis optional on the newCreatedCustomFieldSchemaonly;CustomFieldSchemastill requires it solistkeeps the guarantee. Shape extracted tocustomFieldShapefollowing theclientShapeprecedent in the clients module.CustomFieldsCreateResponse.customFieldschanges fromCustomField[]toCreatedCustomField[]. A type widening — reads of.objectstill compile, but anyone assigning the result toCustomField[]will need a narrow. Worth a look if that's a breaking concern pre-1.0.CustomFieldOptionSchemaneeded no change; it never declaredobject, which is whylistvalidated despite options omitting it too.Verified / not verified
vp checkclean, 200 tests pass. Confirmed the fix is load-bearing: reverting just the schema fails exactly one of the new tests. The create-response fixture is copied verbatim from a real API call, not hand-written.Not verified: whether the omission is intentional or an API bug. If it's a bug, this should be reverted once the API sends the field — both the schema and the README note say so.
🤖 Generated with Claude Code