feat(onboarding): Add SCM messaging treatment route - #120992
Draft
jaydgoss wants to merge 3 commits into
Draft
Conversation
github-actions
Bot
added
the
Scope: Frontend
Add the five-step treatment route, defer project creation, and persist a typed messaging destination in the onboarding session. Refs VDY-140
Make selected-platform clearing non-destructive while keeping full legacy exits explicit. Require fresh integration and channel results before treating a restored destination as valid. Refs VDY-140
Un-export useScmMessagingSetupValidation and ScmMessagingProviderKey; both lacked a second consumer and failed knip. VDY-143 lifts the hook out when the inline picker needs it. Every provider helper in organization_integration_channels.py returns an empty list when the upstream API call fails, so results: [] cannot be distinguished from a deleted channel. Resetting on it discarded a valid destination during a transient Slack or Discord outage. Only a populated list that omits the saved channel now counts as stale.
jaydgoss
force-pushed
the
feat/vdy-140-treatment-route-state
branch
from
July 31, 2026 22:14
35e346f to
9601f27
Compare
jaydgoss
changed the base branch from
feat/vdy-140-scm-messaging-experiment-flag
to
feat/vdy-140-onboarding-session-semantics
July 31, 2026 22:14
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.
TLDR
Adds the treatment-only fifth SCM onboarding step between platform/features and SDK setup, preserving the four-step control flow. Messaging destination state survives refresh and Back, and treatment entry creates no project.
Details
Stacked on #121022, which makes onboarding session exits explicit and is the prerequisite for persisting anything that must outlive a platform change; that in turn sits on #120981, which registers the distinct
onboarding-scm-messaging-experimentkey. The FlagPole config is getsentry/sentry-options-automator#9012, deliberately scoped to a single throwaway developer alias.This layer establishes only the route and the session contract. It has no forward navigation on completion by design: VDY-141 owns shared project and alert-rule creation on final Continue or Set up later, VDY-143 owns inline destination configuration, and VDY-146 owns exposure and interaction analytics. A placeholder
onCompletehere would be deleted by VDY-141 and would strand users on a blanksetup-docs, which renders offrecentCreatedProjectand bails when absent. Because treatment cannot complete yet, the flag must not widen beyond that alias until VDY-141 lands.The onboarding host consumes the nested assignment without reporting exposure and selects separate control and treatment step descriptors from entry, sharing the Welcome and repository steps.
ScmPlatformFeatureskeeps the existing control creation boundary but only stages platform and feature choices for treatment before advancing toscm-messaging;deferProjectCreationalso drops the teams/projects store gate, which only the auto-create path needs. Global Skip resets the onboarding session and exits without creating a project.Steppergainedrole="progressbar"witharia-valuemax, making the four- versus five-step split both accessible and assertable.OnboardingContextProviderpersists a typedunconfigured,skipped, or completed messaging destination in the existing session value, as a discriminated union so a partially-filled destination is unrepresentable. Because #121022 made field setters local, SCM repository, platform, refresh, and Back paths all preserve organization-scoped messaging state.The messaging route re-fetches the saved active integration and channel before treating a restored destination as valid. Cached values stay non-submittable while either query is fetching, and a missing integration resets the state to
unconfiguredwith an explanation. An empty channel list is deliberately not treated as staleness: every provider helper inorganization_integration_channels.pyreturns[]when its upstream API call fails, soresults: []cannot be distinguished from a deleted channel, and resetting on it would discard a valid destination during a transient Slack or Discord outage. Only a populated list that omits the saved channel counts as stale.Coverage exercises the four- versus five-step split, deferred creation, session remount and Back behavior, global Skip, stale integration and channel IDs, the empty-list outage case, and a stale query cache — that last one asserts a restored destination is not shown as selected while revalidation is still in flight.
Refs VDY-140