June 2026 release notes with screenshots#274
Conversation
|
Warning Review limit reached
Next review available in: 8 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis pull request adds a new MDX documentation file for June 2026 platform release notes. It covers a beta experiment creation form, changelog support for experiments and feature flags, customisable stopped reasons, a Metric Usage Report, export lifecycle webhooks with a fix for an export file cleanup race condition, RE2-compatible regex validation in metric filters, and placeholder sections for bug fixes and feedback. Estimated code review effort: 1 (Trivial) | ~3 minutes Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/platform-release-notes/2026/06.mdx`:
- Around line 19-20: The release notes still contain TODO image placeholders
instead of the promised screenshots, so update the markdown to include the
missing visuals before merging. Replace the placeholder in the relevant
changelog section with the correct screenshot reference, and make sure any other
matching TODO on this page is also resolved so both sections render the intended
image content.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 63899943-86da-4650-a3dc-7508a987524c
⛔ Files ignored due to path filters (2)
static/img/release-notes/metric-usage-report.pngis excluded by!**/*.pngstatic/img/release-notes/new-experiment-form.pngis excluded by!**/*.png
📒 Files selected for processing (1)
docs/platform-release-notes/2026/06.mdx
| <!-- TODO: add image release-notes/experiment-changelog.png --> | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add the missing screenshots before merging.
Both changelog sections still use TODO placeholders instead of the screenshots this page promises, so the release notes ship without the visual context readers expect.
Also applies to: 55-55
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/platform-release-notes/2026/06.mdx` around lines 19 - 20, The release
notes still contain TODO image placeholders instead of the promised screenshots,
so update the markdown to include the missing visuals before merging. Replace
the placeholder in the relevant changelog section with the correct screenshot
reference, and make sure any other matching TODO on this page is also resolved
so both sections render the intended image content.
✅ Deploy Preview for absmartly-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
|
||
| ## Overview | ||
|
|
||
| This release is headlined by the **beta of the new experiment creation form** and the new **Metric Usage Report** — a dedicated workspace for understanding where every metric is used, by whom, and how its adoption is trending. We're also extending the changelog introduced in May to **experiments and feature flags**, and adding end-to-end **webhook coverage for the export lifecycle** so customers can fully automate getting experiment data into their warehouse. On top of that, **stopped reasons are now customisable** per account, and we've hardened **regex validation** in metric filters to keep a single bad pattern from breaking an entire experiment. |
There was a problem hiding this comment.
| This release is headlined by the **beta of the new experiment creation form** and the new **Metric Usage Report** — a dedicated workspace for understanding where every metric is used, by whom, and how its adoption is trending. We're also extending the changelog introduced in May to **experiments and feature flags**, and adding end-to-end **webhook coverage for the export lifecycle** so customers can fully automate getting experiment data into their warehouse. On top of that, **stopped reasons are now customisable** per account, and we've hardened **regex validation** in metric filters to keep a single bad pattern from breaking an entire experiment. | |
| This release is headlined by the **beta of the new experiment creation form** and the new **Metric Usage Report** - a dedicated workspace for understanding where every metric is used, by whom, and how its adoption is trending. We're also extending the changelog introduced in May to **experiments and feature flags**, and adding end-to-end **webhook coverage for the export lifecycle** so customers can fully automate getting experiment data into their warehouse. On top of that, **stopped reasons are now customisable** per account, and we've hardened **regex validation** in metric filters to keep a single bad pattern from breaking an entire experiment. |
There was a problem hiding this comment.
Also, the regex validation isn't in this release - it'll be in the next one 🙏
|
|
||
| Each entry shows who made the change, when it happened, a short summary, and **field-level before/after diffs** grouped into clear sections. This is especially valuable when reviewing why an experiment behaved differently after a mid-flight edit, or auditing how a test evolved from setup to stop. | ||
|
|
||
| <!-- TODO: add image release-notes/experiment-changelog.png --> |
|
|
||
| Similar to Experiments, change logs are now also available for **feature flags** — every modification is captured over the flag's lifetime, so you can always see **what changed, who changed it, and when**, including changes to rollout configuration, targeting, and variants. | ||
|
|
||
| <!-- TODO: add image release-notes/feature-flag-changelog.png --> |
| ### RE2-Compatible Regex Validation in Metric Filters | ||
|
|
||
| User-supplied regular expressions in metric filters are now validated on **both the frontend and the backend** using **RE2-compatible** semantics — the same engine ClickHouse uses to evaluate them. | ||
|
|
||
| In practice this means: | ||
|
|
||
| - Invalid patterns are caught **inline at edit/save time** with a clear error, and can no longer be saved through the API. | ||
| - An invalid regex sneaking through (e.g. a legacy saved value) **no longer breaks the entire experiment's metrics query** with a 500 — the engine path degrades gracefully and flags the offending metric instead. | ||
|
|
||
| This was triggered by a real incident where a single bad pattern took down the metrics query for an entire experiment. Tightening validation at every layer makes that class of failure go away for good. | ||
|
|
||
| --- |
There was a problem hiding this comment.
| ### RE2-Compatible Regex Validation in Metric Filters | |
| User-supplied regular expressions in metric filters are now validated on **both the frontend and the backend** using **RE2-compatible** semantics — the same engine ClickHouse uses to evaluate them. | |
| In practice this means: | |
| - Invalid patterns are caught **inline at edit/save time** with a clear error, and can no longer be saved through the API. | |
| - An invalid regex sneaking through (e.g. a legacy saved value) **no longer breaks the entire experiment's metrics query** with a 500 — the engine path degrades gracefully and flags the offending metric instead. | |
| This was triggered by a real incident where a single bad pattern took down the metrics query for an entire experiment. Tightening validation at every layer makes that class of failure go away for good. | |
| --- |
…gex validation section
Summary by CodeRabbit
New Features
Bug Fixes