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

feat: change access-api wrangler.toml to be no_bundle=false. use wrangler bundling #739

Merged
merged 25 commits into from
Apr 14, 2023

Conversation

gobengo
Copy link
Contributor

@gobengo gobengo commented Apr 11, 2023

Motivation:

Experiment

  • I wanted to try some new ways of building and whether they would work, but without risking staging, so I used the 'dev' environment from wrangler.toml to try some deploys from local.
  • I made access-api use of wrangler more like toucan-js@3 wrangler-basic
  • I did a sample deploy from my laptop to 'dev' workers environment, with the sentry/toucan release called bengo-dev-0 sentry errors here
  • trigger error via GET /.debug/error
    • expectation: this to lead to an in-route error and show up in sentry with helpful stack traces - because this is what example implies should work
  • trigger error via route that uses d1 binding (e.g. ucanto routes triggered via w3up+ucanto observable pointing to dev env)
    • expectation: d1 error - because supposedly no_bundle=false (or omitting no_bundle) is incompatible with wrangler d1 bindings

Findings:

  • omg it works!
  • error triggered by GET /.debug/error (no d1)
  • error triggered by using d1 via access protocol via observable
    • The error did not happen in the access/authorize handler. That worked fine, and I got an email from dev env. The error happened when I clicked the email (invoking access/confirm), when the access/confirm invoacation handler tried to write to d1
    • It got a D1_ERROR, but I could see from the sentry report

      Error: ERROR 9009: SQL prepare error: no such table: delegations_v3

    • which makes sense, because dev doesn't have latest migrations applied that created that table. So I provisioned a new d1 database for this dev env, and ran npx wrangler --env=dev d1 migrations apply __D1_BETA__. This would error every couple migrations, but if I re-ran it it would make progress and error again (Internal error [code: 7501]), but eventually it would succeed at all migrations.
    • then I re-triggered things via the observable, get email, click email. I saw 'email validated'! 🎉
    • I continued using the observable to invoke access/claim (reads from D1), and got no error all the way through invoking from second device
      Screenshot 2023-04-10 at 5 48 41 PM

@gobengo gobengo changed the title change access-api wrangler.toml to be no_bundle=false. use wrangler bundling feat: change access-api wrangler.toml to be no_bundle=false. use wrangler bundling Apr 11, 2023
@gobengo gobengo marked this pull request as ready for review April 11, 2023 21:06

[vars]
ENV = "dev"
DEBUG = "true"
DID = "did:web:local.web3.storage"
PRIVATE_KEY="MgCYWjE6vp0cn3amPan2xPO+f6EZ3I+KwuN1w2vx57vpJ9O0Bn4ci4jn8itwc121ujm7lDHkCW24LuKfZwIdmsifVysY="
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the same value from repo /.env.tpl , so it is already public

@gobengo gobengo requested review from Gozala and olizilla April 13, 2023 16:15
@gobengo gobengo temporarily deployed to dev April 13, 2023 16:42 — with GitHub Actions Inactive
@gobengo
Copy link
Contributor Author

gobengo commented Apr 13, 2023

  • create env.ACCOUNT_VERSION string at build time, and have access-api pass it to toucan as opts.release - previously this would get injected via esbuild at custom build time

@gobengo gobengo temporarily deployed to dev April 13, 2023 21:58 — with GitHub Actions Inactive
@gobengo gobengo temporarily deployed to dev April 14, 2023 00:02 — with GitHub Actions Inactive
@gobengo gobengo temporarily deployed to dev April 14, 2023 00:16 — with GitHub Actions Inactive
@gobengo gobengo temporarily deployed to dev April 14, 2023 00:50 — with GitHub Actions Inactive
@gobengo
Copy link
Contributor Author

gobengo commented Apr 14, 2023

How I tested this:

Copy link
Contributor

@olizilla olizilla left a comment

Choose a reason for hiding this comment

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

Is good. Comments inline but nothing blocking, so approving this on the assumption you will tweak or explain as required.

working-directory: packages/access-api
run: |
# write ./dist/index.{js,js.map}
pnpm exec wrangler --env="$ENV" publish --dry-run --outdir=dist
Copy link
Contributor

Choose a reason for hiding this comment

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

my assumption here is that the step before should already generate these as part of the wrangler action. I'd feel more comfortable here if the artefacts are build once and then sent to the places they need to go, rather than relying on the build definitely always being reproducible (it should be, but, if why tempt fate in our error reporting)

what does SENTRY_UPLOAD do in that previous step? is it unused, or does wrangler-action actually upload a thing to sentry (that would be surprising)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

what does SENTRY_UPLOAD do in that previous step? is it unused, or does wrangler-action actually upload a thing to sentry (that would be surprising)

Nothing atm. (because now wrangler.toml doesn't define a custom build command that might read it).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

my assumption here is that the step before should already generate these as part of the wrangler action.

Good suggestion. I had thought so too, and tried that, but iirc it didn't write the files.

Let me see if it's just because I need to pass --outdir=dist on the previous non-dry-run publish.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added a commit to only invoke wrangler publish once (via wrangler-action with custom command to pass --outdir dist) 3af1c35

Comment on lines +30 to +52
async function main(argv = process.argv) {
const cli = sade('access-api-release')
cli
.command('name', '', { default: true })
.option('--env', 'Environment', process.env.ENV)
.action((opts) => {
const releaseName = getReleaseName(opts.env)
console.log(releaseName)
})
cli
.command('esm', 'print release info as ES Module string')
.option('--env', 'Environment', process.env.ENV)
.action((opts) => {
const lines = [
`/** @type {string|undefined} */`,
`export const gitRevShort = '${git.short(__dirname())}'`,
`/** @type {string|undefined} */`,
`export const name = '${getReleaseName(opts.env)}'`,
]
console.log(lines.join('\n'))
})
cli.parse(argv)
}
Copy link
Contributor

Choose a reason for hiding this comment

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

this is neat, but note that our other projects do this by injecting these in as variables into the bundle at build time.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They do that using no_bundle=true and injection via custom esbuild, so this is a way of doing it with no_bundle=false.
Yes it's different, but it seems worth it in order to get the stack traces.

If there's another way that works that seems better, lmk and I can try to implement.

Comment on lines 43 to 45
rules = [
{ type = "Text", globs = ["package.json"], fallthrough = true }
]
Copy link
Contributor

Choose a reason for hiding this comment

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

what dis?

Copy link
Contributor Author

@gobengo gobengo Apr 14, 2023

Choose a reason for hiding this comment

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

I believe this was required for cloudflare workers to be able to import the package.json, which
I think it's a bundler-independent way of providing enough information about whether importing from that json file should result in a string Text or a json-parsed object.
https://developers.cloudflare.com/workers/wrangler/configuration/#bundling

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think I need it anymore, since now release.node.js imports it in node at build time, and writes a rendered value for cloudflare to import via ESM (so it doesn't need to import the package.json to build the rendered version).

I'll remove it

@@ -28,43 +25,52 @@ database_id = "7c676e0c-b9e7-4711-97c8-7b1c8eb229ae"
[[r2_buckets]]
binding = "DELEGATIONS_BUCKET"
bucket_name = "w3up-delegations-dev-0"
preview_bucket_name = "w3up-delegations-dev-0"
Copy link
Contributor

Choose a reason for hiding this comment

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

some changes in this file seem unrelated to bundling / getting stack traces to work. not a blocker, but can you confirm why these changes are needed in this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This one was suggested by wrangler cli when I was deploying to dev env. The dev env has been usused for a bit, so I think we just hadn't exercised that path, so this makes sense as an addition that makes deploying to dev better (seemingly unrelated to d1/sentry/bundling, but the relationship is that the dev env is useful for testing deployments/new-code without disrupting staging, so it was useful here, and is probably useful to commit so others dont run into it when they try to use dev env + wrangler)

@gobengo gobengo temporarily deployed to dev April 14, 2023 17:48 — with GitHub Actions Inactive
@gobengo gobengo merged commit d659516 into main Apr 14, 2023
@gobengo gobengo deleted the 623-no-sentry-ci-push-4 branch April 14, 2023 18:06
@gobengo
Copy link
Contributor Author

gobengo commented Apr 14, 2023

gobengo pushed a commit that referenced this pull request Apr 14, 2023
🤖 I have created a release *beep* *boop*
---


##
[6.1.0](access-api-v6.0.0...access-api-v6.1.0)
(2023-04-14)


### Features

* change access-api wrangler.toml to be no_bundle=false. use wrangler
bundling ([#739](#739))
([d659516](d659516))


### Bug Fixes

* access-api cli.js build does sourcemap=external instead of true
([#731](#731))
([d1a35b7](d1a35b7))
* add /.debug/error route
([#732](#732))
([2ca5de8](2ca5de8))
* change access-api src/index.js 'export default' to be an
immediately-defined object in hopes stack traces will work better
([#733](#733))
([a509313](a509313)),
closes [#623](#623)
* toucan-js in access-api does not use RewriteFrame integration
([#729](#729))
([eeb90e6](eeb90e6))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).
travis added a commit that referenced this pull request Apr 17, 2023
…use wrangler bundling (#739)"

This reverts commit d659516.

I believe this commit resulted in the Postmark API key not being set in staging and production -
reverting to test.
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.

2 participants