Synchronize observability settings during versions deploy

[taylorlee]

In addition to logpush and tail_consumers, patch observability settings
on version deploy. This still doesn't quite match the behavior of
"wrangler deploy", which will disable observability if it is not defined
in wrangler.toml (as of #6776), but at least this is more correct for now.

• Tests
  • Tests included
• E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
  • Required
• Public documentation
  • Documentation not necessary because: already exists: https://developers.cloudflare.com/workers/wrangler/configuration/#observability

[changeset-bot]

🦋 Changeset detected

Latest commit: 654ec04

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
wrangler	Patch
@cloudflare/vitest-pool-workers	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

A wrangler prerelease is available for testing. You can install this latest build in your project with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-wrangler-7091

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7091/npm-package-wrangler-7091

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-wrangler-7091 dev path/to/script.js

Additional artifacts:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-create-cloudflare-7091 --no-auto-update

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-kv-asset-handler-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-miniflare-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-pages-shared-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-vitest-pool-workers-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-workers-editor-shared-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-workers-shared-7091

npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11563725138/npm-package-cloudflare-workflows-shared-7091

Note that these links will no longer work once the GitHub Actions artifact expires.

---

[email protected] includes the following runtime dependencies:

Package	Constraint	Resolved
miniflare	workspace:*	3.20241022.0
workerd	1.20241022.0	1.20241022.0
workerd --version	1.20241022.0	2024-10-22

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

[GregBrimble]

What's the desired end state here when it's empty?

[taylorlee]

I'm not sure. When @RamIdeas added versions-deploy, any undefined settings are not synchronized. When @zebp added observability to regular deploy, it defaults to false when undefined.

It would be unfortunate to need to always patch settings to false for undefined observabililty, but that is the simplest way to reconcile them.

[RamIdeas]

If the default is false then how about we remove the default (make it undefined, i.e. falsey) so this just works™️

[taylorlee]

@RamIdeas I'm not sure I follow. The default does seem to be undefined/falsey, but the difference between deploy and versions-deploy is that deploy always patches the full NonVersionedScriptSettings whereas versions-deploy only does so if at least one field is defined.

So deploy with undefined observability will disable it, whereas versions-deploy will leave it unchanged. Should we always patch during versions-deploy? Or conditionally patch during deploy? Or leave them slightly different?

[WalshyDev]

I don't think we should block on this. The behaviour here comes down to wrangler deploy doing something different for OBS compared to logpush/tail consumers, it will disable if it is not in the config. Meanwhile, logpush/tail will stay with their current values.

If we should do the explicit disable here or if deploy should not do that is a whole topic. The fact that OBS is already inconsistent isn't great, I'm happy with it at least being consistent here. I think there's a larger discussion that needs to happen (cc: @tanushree-sharma @nevikashah ) on what the behaviour should actually be in deploy & here.

I think part of this whole "user expectation" behaviour comes to the fact that Wrangler is already kinda inconsistent with these things. If you remove a binding from the config, it isn't inherited, it's removed. However, you need to explicitly disable workers.dev, it isn't disabled on not being there.

Imo, we need to figure out what the behaviour actually should be and be as consistent across the board as possible.

[RamIdeas]

Yep no need to block on this. Sounds like there's a backend inconsistency re the observability field? Either way, I agree we need to decide the desired behaviour cc @tanushree-sharma @nevikashah

[taylorlee]

The backend API is consistent, the inconsistency is whether it's called or not by wrangler. wrangler deploy always calls it, wrangler versions deploy only calls if if one of the 3 observability settings are defined in wrangler.toml

[RamIdeas]

should we display head_sampling_rate with <skipped> if it's not present? to avoid this single-entry nested value

[taylorlee]

I'm happy to go with whatever you suggest, but I would personally find that confusing. logpush: <skipped> means that wrangler left the remote state unchanged. Omitting head_sampling_rate does not skip synchronizing that field, but causes the default behavior of 100% sampling, which may be different from the prior setting.

[taylorlee]

@RamIdeas any qualms with merging this? I think there is more to discuss on how wrangler deploy and wrangler versions deploy treat undefined settings differently, but I don't think that should block making observability handling more correct.