PLU-743: [IF-THEN-THEN-V2-17] Deprecate branch name

[ogp-weeloong]

Context

We are enabling steps to be inserted after If-thens. The main changes:

1. Introduce a endStepId marker in each if-then step, so that we know when the conditional steps end.
   1. The region between an If-Then action and its end step is called a "block".
   2. For empty blocks, the endStepId is set to the if-then's step ID.
2. Abandon the branch concept because its extra complexity.

Important

Important

This new If-Then is called If-Then V2 in the codebase; we don't want to make a big bang change.

This PR

Deprecates the branchName parameter for If-Then V2. High level approach:

1. Make branchName an optional param (we expect to move people to V2 ASAP so this shouldn't be too big of a problem)
2. Add an edge case to argsToDisplay to hide branch name - this is bad (tm) but I'll clean it up once v2 is rolled out fully.

Edge case: a branch might have both step name and branch name. In this case, we display it as ${branchName} (${customStepName}).

Tests

This is the top stack in the PR, so here are the tests:

With LD flag OFF

• Check that published legacy pipes' If-Then still work.
• Check that I cannot add If-Then in an If-Then
• Check that I cannot add For-Each in an If-Then.
• [Legacy pipe] Check that I can only add If-Then at the end of a pipe without For-Each
• [Legacy pipe] Check that I can only add If-Then at the end of For-Each, in a pipe with For-each
• [Legacy pipe] Check that I cannot add steps after If-then.
• [Legacy pipe] Check that I cannot add steps after If-then when the If-Then is in a For-each.
• [Legacy pipe] Check that when I create a new If-Then branch in a legacy pipe with existing If-Then, stepIdToJumpTo is not populated
• [Legacy pipe] Check that when I create a new If-Then block in a pipe without existing If-then, stepIdToJumpTo is not populated.
• [Legacy pipe] Check that I can re-order branches within an If-Then block, and the new step order is respected when the pipe runs
• [Legacy pipe] Check that I can re-order steps outside the If-Then block, and the new step order is respected when the pipe runs

With LD flag ON

• Check that all If-Thens (>=1 block) in published pipe work.
• Check that I cannot add If-Then in an If-Then.
• Check that I cannot add For-Each in an If-Then.
• Check that I can add steps after If-Then
• Check that I can add steps after an If-Then located in a For-Each
• Check that I can add If-Then in the middle of a pipe.
• Check that I can add If-Then in the middle of a For-Each
• Check that when I create a new If-Then block in a pipe without any If-Then, stepIdToJumpTo is populated.
• Check that when I create a new If-Then block in a For-Each in a pipe without any If-Then, stepIdToJumpTo is populated.
• Check that I can re-order steps outside If-Then (both before and after), and the new step order is respected when the pipe runs
• Check that I can re-order steps outside If-Then (both before and after) within a For-Each, and the new step order is respected when the pipe runs
• [Legacy -> new] Check that I can add steps after an If-Then when the pipe has a legacy If-then (i.e. no stepIdToJumpTo), and that the added steps run outside of the If-Then conditional
• [Legacy -> new] Check that I can add steps after an If-Then in a For-Each when the pipe has a legacy If-then (i.e. no stepIdToJumpTo), and that the added steps run outside of the If-Then conditional

[ogp-weeloong]

• PLU-743: [IF-THEN-THEN-V2-17] Deprecate branch name #2002 👈 (View in Graphite)
• PLU-743: [IF-THEN-THEN-V2-16] Filter away conditionally accessible variables #1955
• PLU-743: [IF-THEN-THEN-V2-15] UX fixes (wrong add step button & selectivity)  #1954
• PLU-743: [IF-THEN-THEN-V2-14] Support adding steps after If-Then V2 #1953
• PLU-743: [IF-THEN-THEN-V2-13] Support adding / deleting / re-ordering If-Then V2 in frontend #1952
• PLU-743: [IF-THEN-THEN-V2-12] Add LD flag for If-Then v2 #1951
• PLU-743: [IF-THEN-THEN-V2-11] Support rendering If-Then V2 blocks in frontend #1950
• PLU-743 [IF-THEN-THEN-V2-10] Opportunistically upgrade if-then V1 blocks to V2 #1963
• PLU-743: [IF-THEN-THEN-V2-9] Prevent publishing with invalid endStepIds #1962
• PLU-743: [IF-THEN-THEN-V2-8] Support remapping endStepId when duplicating #1961
• PLU-743: [IF-THEN-THEN-V2-7] Support updating endStepId when re-ordering steps #1960
• PLU-743: [IF-THEN-THEN-V2-6] Support updating endStepId when deleting step #1959
• PLU-743: [IF-THEN-THEN-V2-5] Make updateStep support endStepId #1968
• PLU-743: [IF-THEN-THEN-V2-4] Support creating If-then V2 in backend #1967
• PLU-743: [IF-THEN-THEN-V2-3] Add validation rules for endStepId #1966
• PLU-743: [IF-THEN-THEN-V2-2] Update MRF to support If-then V2 #1965 : 1 other dependent PR (#1948 )
• PLU-743: [IF-THEN-THEN-V2-1] Introduce endStepId #1964
• feat/if-then-then-real/trunk

This stack of pull requests is managed by Graphite. Learn more about stacking.

[linear-code]

PLU-743

[kevinkim-ogp]

Code review

Found 2 issues:

1. New fallback string "If-then Branch" is inconsistent with the standardized "If-then" default introduced by this same PR (CLAUDE.md says "ONE TERM PER ENTITY: Do not rotate synonyms. Pick one standard name for an object or concept and use it consistently")

Branch.tsx now falls back to 'If-then Branch' for an unnamed branch, while getStepName.ts in the same PR standardizes the fallback everywhere else (drawer title, block header) to 'If-then'. A user with an unnamed if-then step will see two different labels for the same concept.

plumber/packages/frontend/src/components/FlowStepGroup/Content/IfThen/Branch.tsx

Lines 163 to 170 in 4a91d4d

	<Text
	textStyle="subhead-1"
	color="base.content.default"
	noOfLines={1}
	>
	{(branchSteps[0].parameters.branchName as string) ||
	'If-then Branch'}
	</Text>

plumber/packages/frontend/src/helpers/getStepName.ts

Lines 38 to 42 in 4a91d4d

	return {
	stepName: customStepName || 'If-then',
	defaultStepName: 'If-then',
	}

2. New comment restates the code's own branching logic instead of stating only the non-obvious reason (CLAUDE.md says "ONE WHY PER COMMENT: State the single non-obvious reason the code exists or behaves this way. Do not also trace the code's internal branching or filtering logic in prose. That is still WHAT, even when framed as justification")

The third line ("we combine them if thats the case") just narrates the if condition and combination logic directly below it.

plumber/packages/frontend/src/helpers/getStepName.ts

Lines 26 to 30 in 4a91d4d

	// Edge case: If-then V2 is enabled and viewer is looking at a V1 if-then.
	// V1 if-thens may have both stepname and branch names - we combine them if
	// thats the case.
	if (!isV2 && isIfThenV2Enabled && branchName) {

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[kevinkim-ogp]

lgtm, tested works! few things to clarify:

• branch/step name:
  • should we update the stepName tobranchName for all branches when upgrading from v1 to v2? feels like better UX than to only have some updated and some not
  • small thing: focusing on the step name, then hitting enter without typing anything causes us to end up with Branch 1 (Branch 1)(assuming that 'Branch 1' is the original branch name)
  • feels a little odd to type a new step name -> save -> see the name as branchName (newStepName) (might not be worth it to fix if complex logic is needed)
• small ordering thing with MRF
  • if there are no actions between MRF step 1 and MRF step 2 -> cannot draft the if-then in between
  • add an action between MRF step 1 and MRF step 2 -> can drag if-then inside
• removing MRF steps
  • deleting MRF steps deletes other actions that are below the MRF workflow steps, is this intended?
• we might also want to update the templates to immediately adopt v2?