local.yaml is only loaded in the local environment, and will not be used in
production. To avoid specifying it in both production and local configurations,
use it as a default specified in the code instead (that's the pattern we're
using in other places too from what I remember, maybe we should refactor that
too, but that's a bigger task not tied to this change).
**Tested by**
On a local dev cluster
- Not specifying anything and ensuring that the default is picked
- Specifying an override in museum.yaml and verifying that is used instead
This was primarily for getting the latest Electron, but I ran `yarn
upgrade-interactive` and upgraded the other non-breaking deps (mostly dev) too.
Reason for wanting electron is to try and see if this backport fixes the issue
with our streams not getting faithfully written:
https://github.com/electron/electron/pull/41052
In some ad-hoc and quick testing, I noticed that the new `writeStream` we've
implemented works fine for files up to 128 K, presumably some chunk size, but
then begins to diverge. Sounds similar (but not exactly the same) as this issue:
https://github.com/electron/electron/issues/39658
Unfortunately, this didn't fix the issue we're facing, so our case is perhaps
different.
## Description
Ran into error after clearing search bar of queries by hitting
backspace.
> The error is shown below
> Thank you to the team for considering
## Tests
**Error**
**Fix**
Fixed by wrapping the line-causing error around by an `if` block.
Attempt to solve the following error in the browser's console when trying to
make the request:
[error] download and save failed: TypeError: Failed to construct 'Request':
The `duplex` member must be specified for a request with a streaming body
Supressing it for now since it obscures other important information in the console.
Upstream issue, which currently doesn't have a workaround:
https://github.com/catdad-experiments/libheif-js/issues/23
Full error message:
⚠ ../../node_modules/libheif-js/libheif-wasm/libheif-bundle.js
Critical dependency: require function is used in a way in which dependencies cannot be statically extracted
Import trace for requested module:
../../node_modules/libheif-js/libheif-wasm/libheif-bundle.js
../../node_modules/libheif-js/wasm-bundle.js
../../node_modules/heic-decode/index.js
../../node_modules/heic-convert/index.js
./src/worker/convert.worker.ts
./src/utils/comlink/ComlinkConvertWorker.ts
./src/services/heic-convert/service.ts
...
Refs:
- https://stackoverflow.com/questions/38392697/webpack-umd-critical-dependency-cannot-be-statically-extracted
This is only needed for ML indexing, let us revisit this once the ML flow is
done instead of adding a premature and possibly disk-space heavy optimization.
Fixes: https://github.com/ente-io/ente/issues/1440
There were two issues:
- It was a backward incompatible change to change the scheme from
ente:// to next://. Revert.
- We also need to setup a top level redirect when the user presses back
without making any changes to their subscription.
**Tested by**
Running payments app and desktop app locally, and verifying that
- [x] Signing up for a new account, purchasing a plan and verifying that
we went back to the app as expected
- [x] Existing account, after pressing back from the manage payments
page we go back to the app as expected
