Repository navigation
feat(api-v2): config-resource bundle + /v2/alerts namespace - #224
Merged
Merged
Conversation
Ships four new v2 public API resource groups (30 endpoints), burning down the Phase 1 remainder of docs/api-v2.md: - /v2/ingest_keys — per-org singleton: retrieve (creates on first access) + public/private roll, admin-only - /v2/attribute_mappings — CRUD over ingest-time attribute rewrite rules - /v2/scrape_targets — CRUD + probe + checks; credentials stay write-only; probe surfaces provider failures via a new V2UpstreamError (502) so consumers can tell "upstream misbehaving" from "storage unavailable" (503) - /v2/recommendations — list + dismiss/reopen; mutations return the mutated object (v1 returns the full reconciled list) Also renames the alert groups into a Stripe-style product namespace: /v2/alert_rules|alert_destinations|alert_incidents → /v2/alerts/rules|destinations|incidents. Scope enforcement derives the family from the first path segment, so the three alert scope families collapse into a single alerts:read|write. Object types and public-ID prefixes are unchanged. Breaking for any key scoped with the old alert_*:* families (v2 has no external consumers yet). Web: the API-key scope picker and Settings → API Reference scope table now list the unified alerts family plus the four new config families. Tests: new config-resources.http.test.ts PGlite HTTP round-trips; existing v2 harnesses gain ConfigResourceServiceStubsLayer (every harness must satisfy all mounted groups); OpenAPI surface snapshot and scope tests updated to the new paths/family semantics. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
Your Pullfrog Router balance is exhausted. You have a card on file but auto-reload is disabled, so runs paused once your balance went past the overdraft buffer. Top up balance → · Enable auto-reload →
|
Makisuo
added a commit
that referenced
this pull request
Jul 18, 2026
* feat(web): consume v2 API for the config-resource bundle Migrate the dashboard off the v1 client (`MapleApiAtomClient`) onto the already-shipped v2 endpoints (`MapleApiV2AtomClient`) for the four config-resource groups whose v2 surface (#224) was built but still dark: - ingest_keys (get -> retrieve, reroll* -> roll*) - attribute_mappings (v1 ingestAttributeMappings) - scrape_targets - recommendations (v1 recommendationIssues) Reads stay refetch-based (no txid): manual useAtomRefresh for mappings/recommendations/ingest keys, reactivityKeys for scrape targets. Both clients share appRegistry, so the PlanetScale card's v1 integrations mutations still invalidate the migrated v2 scrape-target list. Notable deltas handled beyond mechanical snake_case/param renames: - v2 payload schemas are Schema.Struct -> pass plain snake_case objects (no `new V2…Params`). - Prefixed public IDs round-trip to raw internal IDs at the client boundary, so row ids and the /recommendations/$recommendationKey route param are unchanged. - v2 lists are cursor-paginated (default 20): attribute_mappings and recommendations page through all pages via a runtime.atom cursor loop; scrape_targets keeps .query(...) with limit:100 to preserve its reactivityKeys invalidation. Left as-is: alert_incidents and scrape_targets listChecks (Electric), and the integrations OAuth group in the catalog (v1). Deleting the now-unused v1 groups is a follow-up. Verified: apps/web typecheck clean; browser e2e for all four groups — reads + create/update/delete/probe/dismiss/reopen hit /v2/... with correct snake_case shapes and refetch reconciliation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * m * fix iconsistencies with api v2 * stuff * fux * fix Effect review findings * refine v2 pagination and error handling --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This branch was previously deployed
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.
What changed
Four new v2 public API resource groups (30 endpoints) — the config CRUD slice of the Phase 1 remainder in
docs/api-v2.md:/v2/ingest_keyspublic/roll+private/roll/v2/attribute_mappingsamap_…IDs/v2/scrape_targetsprobe+checkshas_credentialson responses); probe maps provider auth/transport failures to a newV2UpstreamError(502), distinct from storage-unavailable (503)/v2/recommendationsdismiss+reopenAll follow the established v2 pattern: annotated snake_case
Schema.Structwire models, Stripe list/error envelopes, prefixed public IDs (prefixes were already reserved), thin handler adapters over the existing services.Alerts moved into a product namespace:
/v2/alert_rules|alert_destinations|alert_incidents→/v2/alerts/rules|destinations|incidents(Stripecheckout/sessions-style). Since the scope family is derived from the first path segment under/v2, the three alert families collapse into a singlealerts:read|write. Object types (alert_rule, …) and ID prefixes (alrt_,dest_,inc_) are unchanged.Web: the API-key scope picker (
create-api-key-dialog.tsx) and Settings → API Reference scope table (developer-section.tsx) now show the unifiedalertsfamily plus the four new families (which were missing from the key-creation UI). API clients need no path changes — they derive from the sharedMapleApiV2contract.Why
Continues the v2 rollout (
docs/api-v2.mdPhase 1). The config bundle was the fastest burn-down (small CRUD groups, reserved prefixes, existing services). The alerts rename groups three inseparable resources under one namespace and one scope while v2 still has no external consumers — the only time this rename is cheap.Reviewer notes
/v2/alert_*paths now 404, and API keys scoped withalert_rules:*-style families lose alert access — no compat shim, per discussion. Dashboard-minted scoped keys predating this need re-minting if they used alert scopes.mapCommonError/mapMutationError/mapProbeError) because a single wide union doesn't typecheck against endpoints declaring narrower error lists.v2-test-support.tsgainsConfigResourceServiceStubsLayer; every v2 HTTP harness must provide it (HttpApiBuilder.layer(MapleApiV2)requires all groups).encodePublicIdencodings —openapi.test.tsdecodes them.Verification
bun typecheckclean across all packagesconfig-resources.http.test.tsPGlite HTTP round-trips: CRUD, scope enforcement, key rolling, 400/404 envelopes); domain: 216 pass; web alerts: 51 pass/v2/docsrenders all groups;GET /v2/alerts/rules→ 401 (auth),GET /v2/alert_rules→ 404🤖 Generated with Claude Code