chore: restricting scheduled release UI

[jordanl17]

Description

With upcoming changes to the state machine, an ASAP release will briefly pass through the scheduling and scheduled states before moving to publishing and published.

The condition we reuse for determining whether to show the scheduled release UI elements (eg CTAs to schedule/unschedule) currently only checks on the state. This won't be enough when the above state machine change is made - ASAP releases will wrongly at times be shows as scheduled releases.

This change just restricts the condition, requiring that metadata.releaseType is scheduled first.

What to review

Does restricting the conditions for a scheduled release with a releaseType assertion make sense?

Testing

No regressions expected. Manually tested a few hot spots

Notes for release

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 5, 2025 11:31am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 5, 2025 11:31am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 5, 2025 11:31am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Feb 5, 2025 11:31am
test-next-studio	⬜️ Ignored (Inspect)			Feb 5, 2025 11:31am

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Feb 5, 2025 11:33 AM (UTC)

❌ Failed Tests (1) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 8s	15	0	0
formBuilder/ArrayInput.spec.tsx	✅ Passed (Inspect)	12s	3	0	0
formBuilder/inputs/PortableText/Annotations.spec.tsx	❌ Failed (Inspect)	1m 20s	5	0	1
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx	✅ Passed (Inspect)	52s	11	7	0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx	✅ Passed (Inspect)	0s	0	12	0
formBuilder/inputs/PortableText/Decorators.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx	✅ Passed (Inspect)	14s	3	0	0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx	✅ Passed (Inspect)	28s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 8s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 32s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	2m 4s	21	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	26s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 44s	21	0	0
formBuilder/tree-editing/TreeEditing.spec.tsx	✅ Passed (Inspect)	0s	0	3	0
formBuilder/tree-editing/TreeEditingNestedObjects.spec.tsx	✅ Passed (Inspect)	0s	0	3	0

[github-actions]

⚡️ Editor Performance Report

Updated Wed, 05 Feb 2025 11:35:59 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	22.5 efps (45ms)	24.4 efps (41ms)	-4ms (-7.9%)	✅
article (body)	70.2 efps (14ms)	67.3 efps (15ms)	+1ms (-/-%)	✅
article (string inside object)	26.7 efps (38ms)	24.7 efps (41ms)	+3ms (+8.0%)	✅
article (string inside array)	22.7 efps (44ms)	21.3 efps (47ms)	+3ms (+6.8%)	✅
recipe (name)	48.8 efps (21ms)	50.0 efps (20ms)	-1ms (-2.4%)	✅
recipe (description)	52.6 efps (19ms)	55.6 efps (18ms)	-1ms (-5.3%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	+0ms (-/-%)	✅
synthetic (title)	18.7 efps (54ms)	18.9 efps (53ms)	-1ms (-0.9%)	✅
synthetic (string inside object)	18.9 efps (53ms)	19.6 efps (51ms)	-2ms (-3.8%)	✅

efps — editor "frames per second". The number of updates assumed to be possible within a second.

Derived from input latency. efps = 1000 / input_latency

Detailed information

🏠 Reference result

The performance result of sanity@latest

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	45ms	51ms	78ms	439ms	610ms	11.7s
article (body)	14ms	17ms	26ms	190ms	416ms	5.9s
article (string inside object)	38ms	42ms	50ms	296ms	357ms	7.0s
article (string inside array)	44ms	45ms	47ms	170ms	292ms	7.0s
recipe (name)	21ms	22ms	24ms	33ms	0ms	8.3s
recipe (description)	19ms	20ms	22ms	36ms	0ms	4.6s
recipe (instructions)	5ms	6ms	8ms	19ms	0ms	3.0s
synthetic (title)	54ms	60ms	69ms	281ms	1053ms	13.3s
synthetic (string inside object)	53ms	56ms	62ms	513ms	1456ms	8.9s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	41ms	52ms	69ms	434ms	726ms	10.1s
article (body)	15ms	18ms	51ms	256ms	352ms	5.3s
article (string inside object)	41ms	43ms	53ms	65ms	385ms	7.2s
article (string inside array)	47ms	50ms	58ms	252ms	351ms	7.7s
recipe (name)	20ms	21ms	24ms	40ms	0ms	8.2s
recipe (description)	18ms	19ms	20ms	29ms	0ms	4.5s
recipe (instructions)	5ms	6ms	7ms	23ms	0ms	3.0s
synthetic (title)	53ms	54ms	60ms	363ms	796ms	13.6s
synthetic (string inside object)	51ms	56ms	66ms	431ms	700ms	8.3s

📚 Glossary

column definitions

• benchmark — the name of the test, e.g. "article", followed by the label of the field being measured, e.g. "(title)".
• latency — the time between when a key was pressed and when it was rendered. derived from a set of samples. the median (p50) is shown to show the most common latency.
• p75 — the 75th percentile of the input latency in the test run. 75% of the sampled inputs in this benchmark were processed faster than this value. this provides insight into the upper range of typical performance.
• p90 — the 90th percentile of the input latency in the test run. 90% of the sampled inputs were faster than this. this metric helps identify slower interactions that occurred less frequently during the benchmark.
• p99 — the 99th percentile of the input latency in the test run. only 1% of sampled inputs were slower than this. this represents the worst-case scenarios encountered during the benchmark, useful for identifying potential performance outliers.
• blocking time — the total time during which the main thread was blocked, preventing user input and UI updates. this metric helps identify performance bottlenecks that may cause the interface to feel unresponsive.
• test duration — how long the test run took to complete.

[RitaDias]

Good catch!