Skip to content

Allow Triggers as a top-level SDK namespace - #147

Open
ashish-kumar2-glean wants to merge 1 commit into
mainfrom
ashish2/0818-allow-triggers-sdk-namespace
Open

Allow Triggers as a top-level SDK namespace#147
ashish-kumar2-glean wants to merge 1 commit into
mainfrom
ashish2/0818-allow-triggers-sdk-namespace

Conversation

@ashish-kumar2-glean

@ashish-kumar2-glean ashish-kumar2-glean commented Aug 18, 2026

Copy link
Copy Markdown

Problem

Transform OpenAPI Specs has failed on every run since askscio/scio#275355 merged (2026-08-18 09:09 UTC), e.g. run 32121315520:

AssertionError: operations with an unexpected top-level SDK namespace:
GET /api/triggers -> triggers
POST /api/triggers -> triggers
... (all 10)

That PR flipped the Platform Triggers API to x-visibility: Public, so its ten operations now survive the visibility filter and reach the transform carrying x-speakeasy-group: triggers (derived from the x-glean-sdk.group scio already declared). post_transform_smoke allowlists the platform top-level SDK namespaces and did not include triggers.

Impact

The failure happens before the spec is written, so it blocks the whole downstream chain:

  • specs/final/platform.yaml still has no triggers endpoints
  • Deploy Specs to GitHub Pages never runs, so Trigger Developer Site Redeploy never dispatches
  • developers.glean.com has no Triggers reference docs

The daily 00:00 UTC cron re-runs the same transform and fails identically, so this does not self-heal.

Fix

Add triggers to platformSegments. It is a Platform API family, which is what that set is for — the comment above it already says the top level is reserved for the Platform API.

The Platform Triggers API went Public in askscio/scio#275355, so all ten
trigger operations now reach the transform carrying x-speakeasy-group:
triggers. post_transform_smoke allowlists the platform top-level SDK
namespaces and did not include triggers, so Transform OpenAPI Specs has
failed on every run since that merge, leaving specs/final without the
triggers endpoints and never dispatching the developer-site redeploy.

Verified by injecting the ten transformed trigger paths into
overlayed_specs/glean-merged-spec.yaml: the assertion reproduces the CI
failure without this change and passes with it.
@ashish-kumar2-glean ashish-kumar2-glean changed the title test: allow the triggers top-level SDK namespace Allow Triggers as a top-level SDK namespace Aug 18, 2026
@ashish-kumar2-glean
ashish-kumar2-glean marked this pull request as ready for review August 18, 2026 15:01
@ashish-kumar2-glean
ashish-kumar2-glean requested a review from a team as a code owner August 18, 2026 15:01
ashish-kumar2-glean added a commit to gleanwork/glean-developer-site that referenced this pull request Aug 18, 2026
The entry date comes from the filename — changelog:entry:new stamps it with
the date the file is created, and nothing re-dates it afterwards (no entry
in the repo carries a date: field). It was created on 2026-08-15, so it
still read Aug 15.

Entries are dated when the change ships, not when it was written; the
Custom Metadata GA entry was even forward-dated four days past its commit.
Triggers cannot publish until gleanwork/open-api#147 unblocks the spec, so
Aug 15 was both stale and earlier than the endpoints will exist.

The slug is the filename minus the date prefix, so the URL is unchanged and
no redirect is needed. Re-date again if this sits before merging.
ashish-kumar2-glean added a commit to gleanwork/glean-developer-site that referenced this pull request Aug 18, 2026
…hip date

Nothing filters future-dated entries: the entry sorts to the top, sets
changelog.json generatedAt, and gets an RSS pubDate and lastBuildDate of
Thu, 20 Aug 2026. Verified by compiling both outputs against the renamed
file.

That is fine here because the entry is not visible until #692 merges, and
#692 is gated on gleanwork/open-api#147, so it cannot publish before the
ship date. Two things to know if that changes:

- Merging earlier than the 20th puts a future date on the live changelog,
  and some feed readers defer items with a future pubDate.
- The automated generator watermarks off the newest entry filename
  (getLatestChangelogEntryDate -> sinceIso = date + 1 day in
  ingestOpenApiCommits), so while this is the newest entry the bot ingests
  only from the 21st and will not pick up 18-20 Aug changes.
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