Skip to content

fix: correct upsertStructuredProperties and removeStructuredProperties examples - #147

Open
Abhinav0905 wants to merge 1 commit into
datahub-project:mainfrom
Abhinav0905:fix/structured-properties-mutation-shape
Open

fix: correct upsertStructuredProperties and removeStructuredProperties examples#147
Abhinav0905 wants to merge 1 commit into
datahub-project:mainfrom
Abhinav0905:fix/structured-properties-mutation-shape

Conversation

@Abhinav0905

Copy link
Copy Markdown

What

Corrects the two Structured Properties examples in
skills/datahub-enrich/references/mutation-reference.md. As written, neither can
succeed against any GMS — both fail GraphQL validation before reaching execution.

Why

I hit this while building a tiering agent on DataHub for the Agent Hackathon: I
copied the documented upsertStructuredProperties example and spent a while
assuming my own setup was at fault.

Run verbatim against DataHub OSS v1.7.0, the documented upsertStructuredProperties
returns two validation errors:

Validation error (SubselectionRequired@[upsertStructuredProperties]) :
  Subselection required for type 'StructuredProperties!' of field 'upsertStructuredProperties'
Validation error (WrongType@[upsertStructuredProperties]) :
  argument 'input' with value 'ObjectValue{...}' ...

and removeStructuredProperties returns one:

Validation error (SubselectionRequired@[removeStructuredProperties]) :
  Subselection required for type 'StructuredProperties!' of field 'removeStructuredProperties'

Three distinct problems:

  1. The input field is structuredPropertyInputParams, not structuredPropertyInputs.
  2. values is [PropertyValueInput!]! — each value is an object ({ stringValue: "..." }
    or { numberValue: 4.0 }), not a bare string.
  3. Both mutations return StructuredProperties! and therefore require a selection set.

Verification

Both corrected forms return zero validation errors against a live GMS v1.7.0
(they proceed to execution and fail only on the deliberately non-existent probe URN
I used, which is the expected behaviour for an unknown asset).

One extra note added

A sentence documenting a silent failure that cost me the most time: sending
stringValue to a NUMBER-typed property is accepted by GraphQL and then dropped
server-side — no error returned, no value stored, and no new aspect version. It is
indistinguishable from search-index lag until you notice the value never changes.
Worth one line in the reference so the next person does not have to work it out.

Docs-only change; no behaviour affected.

…s examples

Both Structured Properties examples in the datahub-enrich mutation reference fail
GraphQL validation and cannot succeed against any GMS.

The input field is structuredPropertyInputParams rather than
structuredPropertyInputs; values is [PropertyValueInput!]! so each entry is an
object rather than a bare string; and both mutations return StructuredProperties!
and so require a selection set. Verified against DataHub OSS v1.7.0: the documented
upsert returns two validation errors and the documented remove returns one, while
both corrected forms return zero.

Also notes that sending stringValue to a NUMBER-typed property is accepted and then
dropped server-side with no error and no stored value.
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