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

Simplify secret:bulk api via script settings #4179

Conversation

matthewdavidrodgers
Copy link
Contributor

Firing PUTs to the secret api in parallel has never been a great solution - each request independently needs to lock the script, so running in parallel is at best just as bad as running serially.

Luckily, we have the script settings PATCH api now, which can update the settings for a script (including secret bindings) at once, which means we don't need any parallelization. However this api doesn't work with a partial list of bindings, so we have to fetch the current bindings and merge in with the new secrets before PATCHing. We can however just omit the value of the binding (i.e. only provide the name and type) which instructs the config service to inherit the existing value, which simplifies this as well. Note that we don't use the bindings in your current wrangler.toml, as you could be in a draft state, and it makes sense as a user that a bulk secrets update won't update anything else. Instead, we use script settings api again to fetch the current state of your bindings.

This simplified implementation means the operation can only fail or succeed, rather than succeeding in updating some secrets but failing for others. In order to not introduce breaking changes for logging output, the language around "${x} secrets were updated" or "${x} secrets failed" is kept, even if it doesn't make much sense anymore.

Author has included the following, where applicable:

Reviewer is to perform the following, as applicable:

  • Checked for inclusion of relevant tests
  • Checked for inclusion of a relevant changeset
  • Checked for creation of associated docs updates
  • Manually pulled down the changes and spot-tested

Note for PR author:

We want to celebrate and highlight awesome PR review! If you think this PR received a particularly high-caliber review, please assign it the label highlight pr review so future reviewers can take inspiration and learn from it.

@matthewdavidrodgers matthewdavidrodgers requested a review from a team as a code owner October 13, 2023 19:47
@changeset-bot
Copy link

changeset-bot bot commented Oct 13, 2023

🦋 Changeset detected

Latest commit: 4653073

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

This PR includes changesets to release 1 package
Name Type
wrangler Minor

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
Copy link
Contributor

github-actions bot commented Oct 13, 2023

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/6629624085/npm-package-wrangler-4179

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

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

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6629624085/npm-package-wrangler-4179 dev path/to/script.js
Additional artifacts:
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/6629624085/npm-package-cloudflare-pages-shared-4179

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


wrangler@3.14.0 includes the following runtime dependencies:

Package Constraint Resolved
miniflare 3.20231016.0 3.20231016.0
workerd 1.20231016.0 1.20231016.0
workerd --version 1.20231016.0 2023-10-16

|

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

@codecov
Copy link

codecov bot commented Oct 13, 2023

Codecov Report

Merging #4179 (4653073) into main (5321826) will decrease coverage by 0.01%.
The diff coverage is 81.08%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #4179      +/-   ##
==========================================
- Coverage   75.32%   75.32%   -0.01%     
==========================================
  Files         223      223              
  Lines       12280    12294      +14     
  Branches     3177     3180       +3     
==========================================
+ Hits         9250     9260      +10     
- Misses       3030     3034       +4     
Files Coverage Δ
packages/wrangler/src/secret/index.ts 83.95% <81.08%> (-4.57%) ⬇️

... and 4 files with indirect coverage changes

@matthewdavidrodgers matthewdavidrodgers force-pushed the matthewrodgers/bulk-secrets branch 2 times, most recently from 94563b6 to cb6ef4c Compare October 17, 2023 15:48
Firing PUTs to the secret api in parallel has never been a great solution -
each request independently needs to lock the script, so running in parallel
is at best just as bad as running serially.

Luckily, we have the script settings PATCH api now, which can update the
settings for a script (including secret bindings) at once, which means we
don't need any parallelization. However this api doesn't work with a
partial list of bindings, so we have to fetch the current bindings and
merge in with the new secrets before PATCHing. We can however just omit
the value of the binding (i.e. only provide the name and type) which
instructs the config service to inherit the existing value, which
simplifies this as well. Note that we don't use the bindings in your
current wrangler.toml, as you could be in a draft state, and it makes
sense as a user that a bulk secrets update won't update anything else.
Instead, we use script settings api again to fetch the current state of
your bindings.

This simplified implementation means the operation can only fail or
succeed, rather than succeeding in updating some secrets but failing for
others. In order to not introduce breaking changes for logging output,
the language around "${x} secrets were updated" or "${x} secrets failed"
is kept, even if it doesn't make much sense anymore.
@penalosa
Copy link
Contributor

I have a slight concern here around race conditions with pulling down settings and then uploading them. Of course, this is what the dashboard does too, so it's not a major concern, but I wonder if it might be possible to support a way to patch the set of bindings accessible to a worker, rather than just replacing them?

@matthewdavidrodgers
Copy link
Contributor Author

it's true, we open up to race conditions here possibly, but A) the race condition can only be with bindings, not script content or any other metadata and B) yeah, the dash is already subject to much worse race conditions. given that we frequently see bulk secret updates take 20s+ in EWC, this feels worth it to me

@matthewdavidrodgers matthewdavidrodgers merged commit dd270d0 into cloudflare:main Oct 30, 2023
19 of 20 checks passed
@matthewdavidrodgers matthewdavidrodgers deleted the matthewrodgers/bulk-secrets branch October 30, 2023 17:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

3 participants