Skip to content

Add category to ComponentType and ComponentTypeInput - #647

Open
jamescarr wants to merge 1 commit into
OpsLevel:mainfrom
jamescarr:jamescarr/component-type-category
Open

jamescarr wants to merge 1 commit into
OpsLevel:mainfrom
jamescarr:jamescarr/component-type-category

Conversation

@jamescarr

Copy link
Copy Markdown
Contributor

What

Adds Category to ComponentTypeInput (write) and ComponentType (read), and adds category to the ComponentType selection set.

category is a plain String on both sides, not an enum. Setting it to infrastructure files the component type under the Infrastructure catalog; default puts it in Components. I've deliberately not added a validator or enum type — the backend treats categories as account-scoped aliases (the same way allowedCategories on relationship definitions does), so a closed set would be wrong.

Relationship to #613

This covers the same ground as #613, which was closed unmerged. Two things are different here:

  • The people value is gone. It isn't creatable in the product, and it's absent from the tests and fixtures.
  • It's rebased onto current main, so it sits on top of the systemRelationship work rather than conflicting with it.

The feature-flag question — please read

@wesleyjellis asked on #613 how this behaves without the feature flag, and I don't think the answer given there was right, so I want to be straight about it rather than paper over it.

The claim was that on a flagless account the field is simply absent and reads "come back as empty". That isn't how GraphQL works: if category isn't in the account's schema, then a query that selects it fails validation outright, and the whole ComponentType read errors rather than degrading. The write side genuinely is safe — omitempty means nothing is sent when unset — but the read side is not, and that's the part this PR changes.

So the risk is specifically: if infra_component_types_ui still gates schema visibility, this PR breaks every ComponentType read on accounts without the flag.

What I can confirm is that category is present in the public introspection (no GraphQL-Visibility: internal header needed) on the account I have access to. What I can't confirm from outside is whether that's because the flag is now on by default for everyone, or just enabled for my account. That's the one thing I need someone with backend visibility to answer:

  • If the field is now unconditionally in the schema, this is good to go as-is.
  • If it's still gated, then adding it to the shared selection set isn't safe at all, and there's no single query that works for both populations — it'd need a capability check or two query variants. Say the word and I'll close this rather than leave it hanging like Add category field to ComponentType and ComponentTypeInput #613.

Testing

task ci is green (lint + full suite, 78.4% coverage). Create/update tests send category and assert it on the response; the list test asserts it's populated across the fixtures.

Made with Cursor

Adds the `category` field that files a component type under a catalog
category, so a custom type can appear in the Infrastructure catalog
alongside RDS and S3 instead of the components catalog.

Verified against the live API (production and the Zapier sandbox
account) before implementing:

  * `category` is a nullable `String` on both `ComponentTypeInput` and
    `ComponentType`, not an enum, so no enum type or validator is added.
  * It is present in the plain public introspection. The
    `GraphQL-Visibility: internal` header is not required.
  * Omitting `category` on update leaves the existing value untouched,
    which is what makes an already-created type adoptable in place.

The input field is `omitempty`, so a caller that never sets a category
sends nothing at all. The read field is part of the normal selection
set rather than being excluded, otherwise the value could be written
but never reconciled.

Co-authored-by: Cursor <cursoragent@cursor.com>
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