From ce5935f235aee8999e9ae2d3b13ed85f042be9af Mon Sep 17 00:00:00 2001 From: Michael Richey Date: Fri, 25 Sep 2026 16:30:57 -0400 Subject: [PATCH 1/2] docs(rum): add RUM resources Best practices note Add a 'RUM resources' subsection under Best practices documenting the intake limitations, partial-CRUD adaptations, and excluded resources for the new RUM resource types. No code changes. Privacy audit: inspected the cumulative diff from main to this stack head across all new model/test/README files. All test fixtures use obviously synthetic values (app-src, app-dst, rf-1, rf-dst, ef-1, op-1, op-dst, sl-1, pl-1, m-1, feat-1, team-platform, rum.metric.count, checkout-flow, prod-replay, rum-config). No real UUIDs, emails, tokens, org ids, or customer data present. --- README.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/README.md b/README.md index 772f50c8..5ff5e34c 100644 --- a/README.md +++ b/README.md @@ -344,6 +344,19 @@ If importing/syncing subset of resources, users should ensure that dependent res See [Supported resources](#supported-resources) section below for potential resource dependencies. +#### RUM resources + +RUM (Real User Monitoring) resources cover application configuration, retention filters, metrics, operations, replay playlists, teams-ownership mappings, and org-level config. Some RUM resources are parent-scoped under a RUM application (`rum_applications`) and are synced after it. + +Limitations and notes: + +- **Intake data is not migrated.** RUM events, analytics/aggregation, replay sessions, and the `.../sessions` playlist associations are intake-tied and out of scope (consistent with this tool's general stance on ingested data). The tool syncs the resource *definitions* only. +- **`rum_operations`** and **`rum_replay_playlists`** are static definitions (name, query, journey rules / name, description). Their `query` fields are RUM query filters (e.g. `@type:view`), not session ids, so no session-id stripping is required. +- **`rum_permanent_retention_filters`** are system-provisioned with fixed ids identical across orgs; the endpoint set is PATCH-only (configure `cross_product_sampling`), so `create` delegates to `update` and `delete` is a no-op. +- **`rum_teams_ownership_mappings`** have no PATCH endpoint; update is implemented as delete-then-recreate. `team_handle` is a stable handle (preserved across orgs by the `teams` resource) and is not remapped; the dependency on `teams` is soft. +- **`rum_config`** is a singleton org setting; only `enforced_application_tags` is configurable. +- **Excluded (cannot fit the import model):** `rum_teams_ownership_rules` (read-only — nothing to mutate) and `rum_retention_quotas` (no list endpoint — cannot enumerate for import). Sync these manually if needed. + | Resource | Dependencies | |----------------------------------------|------------------------------------------------------------------| | authn_mappings | roles, teams | From e526b6e72d2926f3d74d1a846403e7da0a125d18 Mon Sep 17 00:00:00 2001 From: Michael Richey Date: Fri, 25 Sep 2026 17:24:54 -0400 Subject: [PATCH 2/2] docs(rum): fix PATCH-only wording in README Per review: 'the endpoint set is PATCH-only' was inaccurate because the resource is enumerated with GET requests. Clarified that reads use GET but mutations are PATCH-only (no POST/DELETE). --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 5ff5e34c..48e94812 100644 --- a/README.md +++ b/README.md @@ -352,7 +352,7 @@ Limitations and notes: - **Intake data is not migrated.** RUM events, analytics/aggregation, replay sessions, and the `.../sessions` playlist associations are intake-tied and out of scope (consistent with this tool's general stance on ingested data). The tool syncs the resource *definitions* only. - **`rum_operations`** and **`rum_replay_playlists`** are static definitions (name, query, journey rules / name, description). Their `query` fields are RUM query filters (e.g. `@type:view`), not session ids, so no session-id stripping is required. -- **`rum_permanent_retention_filters`** are system-provisioned with fixed ids identical across orgs; the endpoint set is PATCH-only (configure `cross_product_sampling`), so `create` delegates to `update` and `delete` is a no-op. +- **`rum_permanent_retention_filters`** are system-provisioned with fixed ids identical across orgs; reads use GET, but mutations are PATCH-only (configure `cross_product_sampling` — no POST/DELETE), so `create` delegates to `update` and `delete` is a no-op. - **`rum_teams_ownership_mappings`** have no PATCH endpoint; update is implemented as delete-then-recreate. `team_handle` is a stable handle (preserved across orgs by the `teams` resource) and is not remapped; the dependency on `teams` is soft. - **`rum_config`** is a singleton org setting; only `enforced_application_tags` is configurable. - **Excluded (cannot fit the import model):** `rum_teams_ownership_rules` (read-only — nothing to mutate) and `rum_retention_quotas` (no list endpoint — cannot enumerate for import). Sync these manually if needed.