Repository navigation
feat(API): add linked_key field to key list responses #STRINGS-4425 - #1361
Merged
Mikko Karkee (Varpuspaavi) merged 3 commits intoNov 5, 2026
Merged
Conversation
Contributor
API changelog (oasdiff)Doc-only edits (descriptions, examples) do not appear here. |
Member
|
It probably has an issue with optional attributes 🤔 |
…#STRINGS-4425 The Go generator emits references to undefined Nullable<Model> types for nullable inline objects (linked_key, linked_key.parent). Remove nullable from those two objects and keep the null semantics in the descriptions. Also pass the new include_linked_keys argument in KeysApiTest for keysList and keysSearch so the Java test sources compile. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
… #STRINGS-4425 linked_key is null for unlinked keys and parent/children_count are null for the opposite role, so restore nullable on the response schemas. - Move linked_key and its parent into named components (translation_key_linked_key, translation_key_linked_key_parent) with nullable: true, referenced by a plain $ref from translation_key. - Go template: render nullable model-typed fields as *Model instead of *Nullable<Model> (which is never defined). Primitives are unchanged; generated Go for the existing spec is byte-identical. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sven Dunemann (forelabs)
approved these changes
Nov 5, 2026
Mikko Karkee (Varpuspaavi)
deleted the
openapi-sync/strings-app-pr-19356
branch
November 5, 2026 11:31
This was referenced Nov 5, 2026
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
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.
This PR was generated by the
openapi-applyagent in response to a/openapi-sync applyrequest onPhrase-Engineering/strings-app#19356.
What changed in the API
include_linked_keysboolean query parameter. Whentrue, each key object in the response includes alinked_keyfield describing whether the key is a parent, a child, or unlinked in a key-link relationship.include_linked_keysparameter and the samelinked_keyfield, since the search endpoint routes to the sameindexaction.include_linked_keys=false), thelinked_keyfield is omitted entirely from each key object — the response shape is unchanged from before this PR.Source
Notes for reviewers
Pre-existing convention issue (not introduced by this PR): both
paths/keys/index.yamlandpaths/keys/search.yamlcombine"$ref": "../../responses.yaml#/403"with a siblingdescription:on the403response. Per the conventions doc,$refreplaces the entire object and siblings are silently ignored. This was present before this change and is out of scope for this PR, but worth a follow-up to either drop the sibling description or write the 403 inline.Opened automatically by the
openapi-applyagent. Review the spec changesagainst the linked strings-app PR; the agent does not vouch for correctness
beyond "the YAML parsed and the documented layout was followed."
Update:
linked_keyshape (nullable)Real responses contain nulls when
include_linked_keys=true:linked_key: null{role: "parent", parent: null, children_count: N}{role: "child", parent: {id, name}, children_count: null}The spec now reflects that:
linked_keyand itsparentare named component schemas (translation_key_linked_key,translation_key_linked_key_parent) withnullable: true, referenced via plain$reffromtranslation_key.children_countis a nullable integer.Nullable<Model>types for nullable model fields.openapi-generator/templates/go/model.mustachenow renders nullable model-typed fields as*Model. Primitives still useNullable<Primitive>. Generated Go for the existing spec is byte-identical with and without the template change.linked_keyis on the sharedtranslation_keyschema, so it also appears (optional, absent unless requested) in the schemas used by GET/PATCH/keys/{id}, POST/keysand the screenshot marker responses. The app only returns it from the list and search endpoints; the field description says so.Checked locally:
make lint; Go generate + build + a JSON decode check (absent andnulldecode to nil); Java main + tests compile; TypeScripttsc; Python deserialization. Not confirmed: PHP/Ruby beyond what CI runs, and the response shape is taken from the strings-app PR description, not from a live API call.🤖 Generated with Claude Code