[research] API Publish with Intermittent script timeout #499
Labels
kind/bug
A bug in existing code (including security flaws)
P4
stack/quality-velocity
topic/devexp
Developer experience improvements, onboard efficiencies, time savers.
Comments
olizilla
added a commit
that referenced
this issue
Sep 30, 2021
Match up the release name reported during deploy with the release name reported at run time. This PR lines things up so releases appear in sentry like `web3-api@<semver>` which it automagically parses nicely. We currently we deploy as `<sort git sha>` but we report as `api-<semver>`. see: https://sentry.io/organizations/protocol-labs-it/releases/web3-api%403.5.1/?project=5866408 - `SENTRY_RELEASE` env var is set during the build, and used for both creating the release at build time and on error reports so they get matched up and our sourcemap is used to unravel the stacktrace. - Rename the bundle to be `worker.js` as that is what cloudflare renames (!?) it to on deploy, and errors are reported as coming from `worker.js` in production, so that has to match or else the source map is not applied. - remove the `//# sourceMappingURL=...` link from the end of the js bundle by switching to `devtool: hidden-source-map` in the webpack config. I have no idea whey this is necessary. see: robertcepa/toucan-js#54 (comment) - add commit info to releases in a way that sentry understands, and can match up to our repo with `setCommits: { auto: true }` see: https://github.com/getsentry/sentry-webpack-plugin#optionssetcommits This fixes our double release counting in sentry and make source maps work for _much error readability_! <img width="848" alt="Screenshot 2021-09-29 at 16 24 53" src="https://user-images.githubusercontent.com/58871/135340773-7f321748-4aae-401e-9dc9-c4ae5d19a696.png"> I have also connected up the repo in Sentry so we can see the commits that go in to the release. <img width="364" alt="Screenshot 2021-09-29 at 21 09 37" src="https://user-images.githubusercontent.com/58871/135341267-d67026d7-881f-4f7b-a314-fbc102c75d37.png"> ### Follow on work - We can spare ourselves from cf worker upload errors by just not uploading our 4MB source map as part of deployment. Use the webpack remove files plugin to delete the source map after it has been uploaded to sentry, as we're just not using in cloudflare! would fix #499 see: #506 - Add COMMITSHA and BRANCH env vars, and a `/version` endpoint to report it as nft.storage does. https://github.com/ipfs-shipyard/nft.storage/blob/7102ad5fc06d90a85027e40fa0aece3429b833e7/packages/api/src/index.js#L58-L64 License: (Apache-2.0 AND MIT) Signed-off-by: Oli Evans <oli@tableflip.io>
|
cc @hugomrdias |
|
hey @vasco-santos are we still experiencing this? |
|
Way less often since #679 but still get it a few times (only in staging I believe, so maybe the production app has different capabilities per the CF plan) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sometimes when publishing to CF workers, or starting a CF Worker in Dev mode, the script timeouts after the build finishes.
It is likely related to the S3 client dependency added to the bundle in #417
I could not replicate this locally, but @olizilla can. On latest releases, it happened once and it might become annoying if it is recurrent. Let's track this and if it is frequent, we should probably just rely on S3 HTTP PutObject API instead, given all the other most used s3 client are not well suited for a browser environment.
The text was updated successfully, but these errors were encountered: