Jakob AckermannandClaude Opus 5
6caa5fc3a3
The hash of empty content is a property of the content rather than of anything stored: every project's empty file has it, whether or not a blob was ever written under it, and a file may reference it before anything has. Eight blob stores were each paying a lookup -- a database query, an HTTP request, a read of a cache that offline mode may be the only thing standing in for -- to be told what the hash already says, and clsi had already reinvented the answer on its own. overleaf-editor-core gains BlobStoreBase, which answers getString for that hash and delegates the rest to the fetchString its subclasses provide. getObject comes with it: four stores spelled out the same JSON.parse of getString, and a fifth wrapped it in a log line. Adopted by history-v1's BlobStore, BackupBlobStore, HashCheckBlobStore and recover_zip's RecoveryBlobStore, by project-history's BlobStore, by clsi's BlobStore, and by web's HistoryBlobStore, SimpleBlobStore and FrontendBlobStore. history-v1 keeps its own answers in getStream, getBlob and getBlobs, which no other store implements. Writing and copying a blob are untouched, so a project that wrote empty content still has a blob for it and a read answers the same either way. Two paths could not handle a project holding a tracked change or a comment at all. Loading such a file needs the ranges blob its rangesHash points at, and hashing one again needs to write it back, so a store missing getObject or putObject fails outright: - recover_zip died on `blobStore.getObject is not a function`, making every such project unrecoverable. The test covering it asserts a tracked delete is absent from the zip, which the script already asked for and never reached. - GET /projects/:project_id/latest/hashed_content returned 500 from the same cause, then would have hit a missing putObject in snapshot.store. HashCheckBlobStore becomes a class over the base and gains putObject. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> GitOrigin-RevId: c84f62465beff6cf77ffac26aa772984e1b554cb
@overleaf/project-history
An API for converting raw editor updates into a compressed and browseable history.
Running project-history
The app runs natively using yarn and Node on the local system:
yarn install
yarn run start
Unit Tests
The test suites run in Docker.
Unit tests can be run in the test_unit container defined in docker-compose.tests.yml.
The makefile contains a short cut to run these:
make install # Only needs running once, or when yarn packages are updated
make test_unit
During development it is often useful to only run a subset of tests, which can be configured with arguments to the mocha CLI:
make test_unit MOCHA_ARGS='--grep=AuthorizationManager'
Acceptance Tests
Acceptance tests are run against a live service, which runs in the acceptance_test container defined in docker-compose.tests.yml.
To run the tests out-of-the-box, the makefile defines:
make install # Only needs running once, or when yarn packages are updated
make test_acceptance
However, during development it is often useful to leave the service running for rapid iteration on the acceptance tests. This can be done with:
make test_acceptance_start_service
make test_acceptance_run # Run as many times as needed during development
make test_acceptance_stop_service
make test_acceptance just runs these three commands in sequence.
During development it is often useful to only run a subset of tests, which can be configured with arguments to the mocha CLI:
make test_acceptance_run MOCHA_ARGS='--grep=AuthorizationManager'
Makefile and yarn scripts
The commands used to compile the app and tests, to run the mocha tests, and to run the app are all in package.json. These commands call out to coffee, mocha, etc which are available to npm in the local node_modules/.bin directory, using the local versions. Normally, these commands should not be run directly, but instead run in docker via make.
The makefile contains a collection of shortcuts for running the yarn scripts inside the appropriate docker containers, using the docker-compose files in the project.
Copyright (c) Overleaf, 2017-2021.