feat(sanity): display release errors

[juice49]

Description

This branch adds release errors to the data model and updates the UI to reflect the presence of a release error. Presence of an error is only taken into account for releases that are in an active state.

This branch does not include a way to deal with a release error. We'll likely want to allow folks to manually publish release, allowing the remaining unpublished documents to be published. Decided to exclude this work for now, because a lot of the publication logic is encoded into the publish button itself, making it tricky to extract into a different context. This is expected to be a very narrow edge case.

What to review

When there are errors present

The releases tool icon is given a small error indicator

The releases list view will display an error indicator in the affected row

The release detail view will show an error indicator at the start

The release detail view will show an error detail UI

Testing

• Added unit tests.

Notes for release

Adds release error details to UI.

[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 6, 2025 10:14am
performance-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 6, 2025 10:14am
test-studio	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 6, 2025 10:14am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Feb 6, 2025 10:14am
test-next-studio	⬜️ Ignored (Inspect)			Feb 6, 2025 10:14am

[github-actions]

No changes to documentation

[github-actions]

Component Testing Report Updated Feb 6, 2025 10:19 AM (UTC)

❌ Failed Tests (1) -- expand for details

File	Status	Duration	Passed	Skipped	Failed
comments/CommentInput.spec.tsx	✅ Passed (Inspect)	1m 6s	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)	51s	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)	27s	6	0	0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx	✅ Passed (Inspect)	1m 7s	15	0	0
formBuilder/inputs/PortableText/Input.spec.tsx	✅ Passed (Inspect)	1m 35s	21	0	0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx	✅ Passed (Inspect)	2m 2s	21	0	0
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx	✅ Passed (Inspect)	13s	3	9	0
formBuilder/inputs/PortableText/Styles.spec.tsx	✅ Passed (Inspect)	27s	6	0	0
formBuilder/inputs/PortableText/Toolbar.spec.tsx	✅ Passed (Inspect)	1m 45s	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 Thu, 06 Feb 2025 10:19:38 GMT

Benchmark	reference latency of sanity@latest	experiment latency of this branch	Δ (%) latency difference
article (title)	22.7 efps (44ms)	23.5 efps (43ms)	-2ms (-3.4%)	✅
article (body)	63.3 efps (16ms)	67.8 efps (15ms)	-1ms (-/-%)	✅
article (string inside object)	24.4 efps (41ms)	25.6 efps (39ms)	-2ms (-4.9%)	✅
article (string inside array)	21.3 efps (47ms)	22.2 efps (45ms)	-2ms (-4.3%)	✅
recipe (name)	50.0 efps (20ms)	48.8 efps (21ms)	+1ms (+2.5%)	✅
recipe (description)	55.6 efps (18ms)	54.1 efps (19ms)	+1ms (+2.8%)	✅
recipe (instructions)	99.9+ efps (5ms)	99.9+ efps (5ms)	+0ms (-/-%)	✅
synthetic (title)	18.0 efps (56ms)	18.9 efps (53ms)	-3ms (-4.5%)	✅
synthetic (string inside object)	18.5 efps (54ms)	19.6 efps (51ms)	-3ms (-5.6%)	✅

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)	44ms	49ms	60ms	455ms	840ms	11.3s
article (body)	16ms	18ms	23ms	217ms	309ms	5.4s
article (string inside object)	41ms	44ms	46ms	151ms	237ms	7.5s
article (string inside array)	47ms	50ms	54ms	245ms	547ms	7.7s
recipe (name)	20ms	21ms	23ms	40ms	0ms	7.6s
recipe (description)	18ms	19ms	21ms	37ms	0ms	4.5s
recipe (instructions)	5ms	7ms	7ms	32ms	0ms	3.1s
synthetic (title)	56ms	58ms	66ms	510ms	1157ms	15.4s
synthetic (string inside object)	54ms	55ms	59ms	440ms	1052ms	8.8s

🧪 Experiment result

The performance result of this branch

Benchmark	latency	p75	p90	p99	blocking time	test duration
article (title)	43ms	64ms	77ms	477ms	943ms	11.6s
article (body)	15ms	16ms	21ms	65ms	205ms	5.1s
article (string inside object)	39ms	41ms	46ms	262ms	282ms	6.8s
article (string inside array)	45ms	47ms	51ms	175ms	456ms	7.4s
recipe (name)	21ms	21ms	24ms	36ms	0ms	6.9s
recipe (description)	19ms	19ms	21ms	29ms	0ms	4.6s
recipe (instructions)	5ms	7ms	8ms	24ms	0ms	3.1s
synthetic (title)	53ms	56ms	82ms	470ms	1104ms	13.3s
synthetic (string inside object)	51ms	54ms	57ms	117ms	750ms	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.