feat: change access-api wrangler.toml to be no_bundle=false

[gobengo]

Motivation:

• access-api stacktraces in sentry are not working #623
• verify our assumption that we have to use no_bundle=true along with d1.

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
    

Next steps:

• (opt) feedback on whether we can rely on this from @olizilla
• develop this PR all the way to
  • make tests pass (tests rely on ./scripts/cli.js e.g. to run migrations, so I probably need to modify cli.js to still work in tests at least)
  • something that will work withour release automation. (locally I had to hardcode env.ACCOUNT_VERSION=bengo-dev-0 just to test the theory)
    • the toucan-js@3 examples hardcode 1.0.0 always. I think I can come up with something better than that quickly tomorrow

[gobengo]

new db because the old one is quite out of date, has no important data, and got hung up on migrations. No one has been using dev afaik so I think this should be safe.

[gobengo]

wrangler asked me to do this when deploy to dev env

[gobengo]

This is from ../../.env.tpl so already public

[gobengo]

I can't think of any downsides. It would accomplish:

• working stack traces in sentry
• access-api use of cloudflare workers is much more like what nftstorage/website and web3-storage/website use

downside

• this uses d1 + no_bundle=false - which is technically not allowed in d1 public alpha, but seems like maybe we are detecting it now works even though they haven't updated docs like https://developers.cloudflare.com/workers/wrangler/bundling/#d1-bindings

Sanity check

• make sure this is actually using d1... it might be good to be true.
  • I believe the fact that my observable requesting access/claim from d1 gets delegations means this isn't using any kind of fall back non-d1 storage. Otherwise the persistence wouldn't work. Also when running access/* handlers on cloudflare, it will only ever build some models using d1. so if d1 binding wasn't available here, that would have error I think

[gobengo]

I force pushed to this source branch and deleted it because I accidentally pushed a commit containing a sentry dsn I used to test. I disabled the DSN in sentry admin, so it's now useless. I followed these docs to delete using git-filter-repo.

It should be impossible to find the accidentally pushed DSN, and if it is found, it should be useless