Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: switch to dated api version for releases #8676

Merged
merged 4 commits into from
Feb 20, 2025

Conversation

bjoerge
Copy link
Member

@bjoerge bjoerge commented Feb 17, 2025

Description

Switches the API version we use for releases from vX to a stable, dated version.

What to review

The diff itself is tiny, but I'd appreciate some manual testing to verify that everything work as intented with regards to content releases.

Next step would be to remove the the feature detection for releases and use v2025-02-19 regardless, but for now, I think it makes sense for us to keep an easy way to enable/disable it for debugging purposes.

Testing

Existing tests should be enough.

Notes for release

n/a

Copy link

vercel bot commented Feb 17, 2025

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 19, 2025 7:41pm
performance-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 19, 2025 7:41pm
test-studio ✅ Ready (Inspect) Visit Preview 💬 Add feedback Feb 19, 2025 7:41pm
2 Skipped Deployments
Name Status Preview Comments Updated (UTC)
studio-workshop ⬜️ Ignored (Inspect) Visit Preview Feb 19, 2025 7:41pm
test-next-studio ⬜️ Ignored (Inspect) Feb 19, 2025 7:41pm

Copy link
Contributor

No changes to documentation

Copy link
Contributor

github-actions bot commented Feb 17, 2025

⚡️ Editor Performance Report

Updated Wed, 19 Feb 2025 19:46:35 GMT

Benchmark reference
latency of sanity@latest
experiment
latency of this branch
Δ (%)
latency difference
article (title) 28.6 efps (35ms) 26.7 efps (38ms) +3ms (+7.1%)
article (body) 71.9 efps (14ms) 72.7 efps (14ms) -0ms (-/-%)
article (string inside object) 28.2 efps (36ms) 25.0 efps (40ms) +5ms (+12.7%)
article (string inside array) 25.0 efps (40ms) 23.3 efps (43ms) +3ms (+7.5%)
recipe (name) 48.8 efps (21ms) 52.6 efps (19ms) -2ms (-7.3%)
recipe (description) 52.6 efps (19ms) 62.5 efps (16ms) -3ms (-15.8%)
recipe (instructions) 99.9+ efps (5ms) 99.9+ efps (5ms) +0ms (-/-%)
synthetic (title) 20.0 efps (50ms) 19.6 efps (51ms) +1ms (+2.0%)
synthetic (string inside object) 19.2 efps (52ms) 19.6 efps (51ms) -1ms (-1.9%)

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) 35ms 39ms 44ms 164ms 127ms 9.7s
article (body) 14ms 16ms 28ms 210ms 350ms 5.5s
article (string inside object) 36ms 39ms 44ms 171ms 149ms 6.5s
article (string inside array) 40ms 42ms 45ms 56ms 125ms 6.5s
recipe (name) 21ms 22ms 24ms 54ms 0ms 7.3s
recipe (description) 19ms 21ms 25ms 48ms 0ms 4.7s
recipe (instructions) 5ms 6ms 7ms 8ms 0ms 3.0s
synthetic (title) 50ms 52ms 58ms 212ms 778ms 12.3s
synthetic (string inside object) 52ms 54ms 66ms 467ms 1305ms 8.5s

🧪 Experiment result

The performance result of this branch

Benchmark latency p75 p90 p99 blocking time test duration
article (title) 38ms 41ms 47ms 381ms 194ms 10.5s
article (body) 14ms 16ms 29ms 102ms 216ms 5.5s
article (string inside object) 40ms 42ms 45ms 164ms 186ms 7.1s
article (string inside array) 43ms 45ms 48ms 189ms 188ms 7.2s
recipe (name) 19ms 20ms 23ms 37ms 0ms 8.0s
recipe (description) 16ms 17ms 19ms 30ms 0ms 4.4s
recipe (instructions) 5ms 7ms 9ms 30ms 0ms 3.1s
synthetic (title) 51ms 56ms 76ms 379ms 1171ms 12.8s
synthetic (string inside object) 51ms 52ms 61ms 107ms 431ms 7.5s

📚 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.

Copy link
Contributor

github-actions bot commented Feb 17, 2025

Component Testing Report Updated Feb 19, 2025 7:50 PM (UTC)

❌ Failed Tests (5) -- expand for details
File Status Duration Passed Skipped Failed
comments/CommentInput.spec.tsx ✅ Passed (Inspect) 1m 25s 15 0 0
formBuilder/ArrayInput.spec.tsx ✅ Passed (Inspect) 14s 3 0 0
formBuilder/inputs/PortableText/Annotations.spec.tsx ❌ Failed (Inspect) 2m 40s 3 0 3
formBuilder/inputs/PortableText/copyPaste/CopyPaste.spec.tsx ✅ Passed (Inspect) 1m 0s 11 7 0
formBuilder/inputs/PortableText/copyPaste/CopyPasteFields.spec.tsx ✅ Passed (Inspect) 0s 0 12 0
formBuilder/inputs/PortableText/Decorators.spec.tsx ✅ Passed (Inspect) 30s 6 0 0
formBuilder/inputs/PortableText/DisableFocusAndUnset.spec.tsx ✅ Passed (Inspect) 17s 3 0 0
formBuilder/inputs/PortableText/DragAndDrop.spec.tsx ✅ Passed (Inspect) 31s 6 0 0
formBuilder/inputs/PortableText/FocusTracking.spec.tsx ❌ Failed (Inspect) 1m 57s 14 0 1
formBuilder/inputs/PortableText/Input.spec.tsx ✅ Passed (Inspect) 1m 53s 21 0 0
formBuilder/inputs/PortableText/ObjectBlock.spec.tsx ❌ Failed (Inspect) 3m 1s 20 0 1
formBuilder/inputs/PortableText/PresenceCursors.spec.tsx ✅ Passed (Inspect) 15s 3 9 0
formBuilder/inputs/PortableText/Styles.spec.tsx ✅ Passed (Inspect) 31s 6 0 0
formBuilder/inputs/PortableText/Toolbar.spec.tsx ✅ Passed (Inspect) 2m 2s 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

Copy link
Contributor

github-actions bot commented Feb 17, 2025

Coverage Report

Status Category Percentage Covered / Total
🔵 Lines 42.97% 54930 / 127814
🔵 Statements 42.97% 54930 / 127814
🔵 Functions 48.13% 2794 / 5805
🔵 Branches 79.49% 10644 / 13390
File Coverage
File Stmts Branches Functions Lines Uncovered Lines
Changed Files
packages/sanity/src/core/studioClient.ts 100% 100% 100% 100%
packages/sanity/src/core/preview/documentPreviewStore.ts 82.75% 100% 33.33% 82.75% 129, 141-148, 173
packages/sanity/src/core/releases/util/releasesClient.ts 100% 100% 100% 100%
Generated in workflow #30729 for commit ab15bec by the Vitest Coverage Report Action

Copy link
Contributor

@RitaDias RitaDias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth moving these apiVersions definitions to a const that we have somewhere and pull from there? I'm thinking future proofing where we eventually will just want to probably have a "source of truth" of what most of our clients will use?

So maybe a const defined in the studioClient that then is imported by the rest?

Copy link
Contributor

@RitaDias RitaDias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything seems to be working as intended, so nothing is blocking but I'd consider this comment: #8676 (review) before merging. If needed I'll give another green again!

Copy link
Contributor

@EoinFalconer EoinFalconer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good from my testing!

@bjoerge
Copy link
Member Author

bjoerge commented Feb 20, 2025

Is it worth moving these apiVersions definitions to a const that we have somewhere and pull from there.

Agree, it's good idea to have a central place to define the API version(s) used by the Studio. I'd suggest we make it a separate task to centralize all places we currently use hard coded strings.

@bjoerge bjoerge merged commit c704980 into next Feb 20, 2025
62 checks passed
@bjoerge bjoerge deleted the sapp-2047-use-dated-api-instead-of-vX branch February 20, 2025 10:11
@RitaDias
Copy link
Contributor

Is it worth moving these apiVersions definitions to a const that we have somewhere and pull from there.

Agree, it's good idea to have a central place to define the API version(s) used by the Studio. I'd suggest we make it a separate task to centralize all places we currently use hard coded strings.

Created the story cc @bjoerge @EoinFalconer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants