[Changelog] Durable Objects Deployments tab - #32692
Conversation
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
|
/bonk review |
|
CI run failed: build logs |
![ask-bonk[bot]](https://avatars.githubusercontent.com/in/2454580?s=60&v=4){kind=small}
|
|
||
| Each version's row now shows both: | ||
|
|
||
| - **Actual** — the percentage of observed requests that version handled in the selected time window, shown as the headline number and the filled portion of the bar. |
There was a problem hiding this comment.
Style guide violation: Do not use bullet points for fewer than three items. Rewrite these two items as sentences instead.
For example:
Each version's row now shows both the Actual and Configured traffic share. Actual is the percentage of observed requests that version handled in the selected time window, shown as the headline number and the filled portion of the bar. Configured is the percentage you set for that version, shown as a tick mark with its own label.
|
I submitted 1 inline comment on the PR. Other notes:
|
iglesiasbrandon
changed the title
|
/bonk review the updated PR |
| @@ -0,0 +1,30 @@ | |||
| --- | |||
| title: View deployments for Durable Objects in the dashboard | |||
| description: Durable Object namespaces now have a Deployments tab showing the backing Worker's active versions, traffic split (actual and configured), and per-version request, error, and wall time metrics. | |||
There was a problem hiding this comment.
Style guide violation: The description is 189 characters, which exceeds the 50–160 character limit. Consider shortening it. For example:
Durable Object namespaces now have a Deployments tab showing the backing Worker's active versions, traffic split, and per-version metrics.
|
I submitted 1 inline comment on PR #32692. Finding:
Validation status:
Note on the previous review: The earlier ask-bonk comment was on |
|
|
||
| <DashButton url="/?to=/:account/workers/durable-objects" /> | ||
|
|
||
| A Durable Object namespace is backed by a Worker script, so its deployments are the same as that Worker's deployments. Previously, checking on a [gradual deployment](/workers/versions-and-deployments/gradual-deployments/) in progress for a Durable Object meant leaving the namespace and finding the backing Worker under Workers & Pages. The new tab surfaces that information directly on the namespace, alongside the metrics that matter for it: requests, error rate, and wall time per version, rather than the CPU time shown on the Worker's own Deployments tab. Wall time better reflects Durable Object performance, since it includes time spent waiting on I/O such as storage reads. |
There was a problem hiding this comment.
| A Durable Object namespace is backed by a Worker script, so its deployments are the same as that Worker's deployments. Previously, checking on a [gradual deployment](/workers/versions-and-deployments/gradual-deployments/) in progress for a Durable Object meant leaving the namespace and finding the backing Worker under Workers & Pages. The new tab surfaces that information directly on the namespace, alongside the metrics that matter for it: requests, error rate, and wall time per version, rather than the CPU time shown on the Worker's own Deployments tab. Wall time better reflects Durable Object performance, since it includes time spent waiting on I/O such as storage reads. | |
| A Durable Object namespace is backed by a Worker script, so its deployments are the same as that Worker's deployments. Previously, checking on a [gradual deployment](/workers/versions-and-deployments/gradual-deployments/) in progress for a Durable Object meant navigating to the backing Worker. The new tab surfaces that information directly on the namespace, alongside the metrics that matter for it: requests, error rate, and wall time per version, rather than the CPU time shown on the Worker's own Deployments tab. Wall time better reflects Durable Object performance, since it includes time spent waiting on I/O. |
|
|
||
| ## Actual vs. configured traffic split | ||
|
|
||
| The **Traffic %** column, for both Workers and Durable Objects, now shows the actual, observed traffic share for each version next to the percentage you configured — shown as the headline number and filled bar, with the configured split marked as a tick. Previously, this column only showed the configured percentage. If you moved a deployment from 50/50 to 100% on a new version, the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere. |
There was a problem hiding this comment.
| The **Traffic %** column, for both Workers and Durable Objects, now shows the actual, observed traffic share for each version next to the percentage you configured — shown as the headline number and filled bar, with the configured split marked as a tick. Previously, this column only showed the configured percentage. If you moved a deployment from 50/50 to 100% on a new version, the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere. | |
| The **Traffic %** column, for both Workers and Durable Objects, now shows the actual, observed traffic share for each version next to the percentage you configured. Previously, this column only showed the configured percentage. If you moved a deployment from 50/50 to 100% on a new version, the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere. |
dont need to describe UI, design/screenshot aims to be self-explantory
If you moved a deployment from 50/50 to 100% on a new version, the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere.
Should user be able to refresh then?
|
|
||
| The **Traffic %** column, for both Workers and Durable Objects, now shows the actual, observed traffic share for each version next to the percentage you configured — shown as the headline number and filled bar, with the configured split marked as a tick. Previously, this column only showed the configured percentage. If you moved a deployment from 50/50 to 100% on a new version, the configured number updated immediately, but requests take time to catch up, and there was no way to tell how far along that shift was without checking metrics elsewhere. | ||
|
|
||
| This gap between actual and configured is especially useful for Durable Objects. Because [each Durable Object is pinned to the version it started on until you create a new deployment](/workers/versions-and-deployments/gradual-deployments/with-durable-objects/), a namespace's observed traffic split can lag its configured split for much longer than a stateless Worker — sometimes for as long as its objects stay alive. Seeing both numbers side by side makes it clear whether a deployment has actually finished rolling out or is still catching up. |
There was a problem hiding this comment.
DO versions apply by object, so the UI tick doesnt make sense to me. This is where DOs are different than a Worker.
You might have a 50% rollout to version A and more than 50% traffic to DO version A. Showing % traffic by version makes sense but the % traffic breakdown does not match gradual deployment %
3 participants
Summary
Adds a single changelog entry for the new Durable Objects Deployments tab in the Cloudflare dashboard, which:
Screenshots
A screenshot of the new Deployments tab is already included in the changelog entry itself (
src/assets/images/changelog/durable-objects/durable-objects-deployments-tab.png).Documentation checklist