ref https://linear.app/tryghost/issue/CFR-4/
- added request queueing middleware (express-queue) to handle high
request volume
- added new config option `optimization.requestQueue`
- added new config option `optimization.requestConcurrency`
- added logging of request queue depth - `req.queueDepth`
We've done a fair amount of investigation around improving Ghost's
resiliency to high request volume. While we believe this to be partly
due to database connection contention, it also seems Ghost gets
overwhelmed by the requests themselves. Implementing a simple queueing
system allows us a simple lever to change the volume of requests Ghost
is actually ingesting at any given time and gives us options besides
simply increasing database connection pool size.
---------
Co-authored-by: Michael Barrett <mike@ghost.org>
- this version is written in TS, but was published a few months ago and
needs to be bumped here
- also updates a previous deep include into the library, which was
unnecessary anyway
fixes GRO-34
fixes GRO-33
This is a revision of a previous commit, that broke the browser tests
because changes in the data generator (requiring bookshelf had side
effects).
This adds a new way to run all tests with enforced numeric ObjectIDs.
These numeric ids cause issues if they are used withing NQL filters. So
they surface tiny bugs in our codebase.
You can run tests using this option via:
NUMERIC_IDS=1 yarn test:e2e
Removed some defensive logic that could be explained by this discovered
issue.
fixes GRO-34
fixes GRO-33
This also adds a new way to run all tests with enforced numeric ObjectIDs.
These numeric ids cause issues if they are used withing NQL filters. So they
surface tiny bugs in our codebase.
You can run tests using this option via:
NUMERIC_IDS=1 yarn test:e2e
Also removed some defensive logic that could be explained by unquoted ids.
refs https://github.com/TryGhost/Product/issues/4159
---
<!-- Leave the line below if you'd like GitHub Copilot to generate a
summary from your commit -->
<!--
copilot:summary
-->
### <samp>🤖[[deprecated]](https://githubnext.com/copilot-for-prs-sunset)
Generated by Copilot at 9e68f4d</samp>
This pull request refactors several components in the `admin-x-settings`
app to use common hooks from the `@tryghost/admin-x-framework` package,
which reduces code duplication and improves consistency. It also updates
the `package.json` file and adds unit tests for the `admin-x-framework`
package, which improves the formatting, testing, and dependency
management. Additionally, it makes some minor changes to the `hooks.ts`,
`FrameworkProvider.tsx`, and `.eslintrc.cjs` files in the
`admin-x-framework` package, which enhance the public API and the
linting configuration.
fixes GRO-25
Updated @tryghost/nql to 0.12.0 and other packages that depend on it
1. SQLite: when a filter string contains /.
When we use a NQL contain/starts/endsWith filter that contains a slash,
underlyingly the whole filter will get converted to a MongoDB query, in
which we just use a regexp to represent the filter. In here we will
escape the slash: \/ as expected in a regexp. Later when we convert this
MongoDB query back to knex/SQL, we use a SQL LIKE query. Currently we
don't remove the escaping here for a normal slash. MySQL seems to ignore
this (kinda incorrect). SQLite doesn't like it, and this breaks queries
on SQLite that use slashes. The solution here is simple: remove the
backslash escaping when converting the regexp to LIKE, just like we do
with other special regexp characters.
2. We don't escape % and _, which have a special meaning in LIKE queries
Usage of % and _ is now as expected and doesn't have the special SQL
meaning anymore.
no issue
- added passthrough of `transaction` property when fetching post IDs otherwise SQLite will error with ` "Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call?"`
refs https://github.com/TryGhost/Arch/issues/95
Rather than storing all of the relations between the latest collection and
posts, we know that it contains all posts. This means we don't have to keep the
collections posts in sync. Instead we can fetch them from the posts table. This
saves a lot of work during recalculation.
refs https://github.com/TryGhost/Arch/issues/95
We're going to be treating the "latest" Collection as a "virtual" Collection
where we will hydrate the posts from the posts repository. This will allow for
more performant queries, and less work to keep the "latest" Collection in sync
Our service layer should not expose the Entities, it should return the DTOs.
This is to allow us to make internal refactors without having to modify the
entire stack.
refs https://github.com/TryGhost/Arch/issues/95
These events can be used to know when an automatic collections posts have been
updated, as well as by the repository to optimise the storage of
CollectionPosts
no issue
`PostsService` and `CollectionsService` were missing some passthroughs and had differing naming for a transaction instance on the `options` object which meant SQLite would hang if the Lexical renderer called out to `PostsService.browsePosts`
- added passthrough of `transacting` to the Lexical renderer ready for implementation of the collection-fetching function
- added rename of `options.transacting` to `options.transaction` and passthrough from `PostsService` to `CollectionsService` (passthrough from collections repository to bookshelf and required `transaction->transacting` was already in place)
refs https://github.com/TryGhost/DevOps/issues/50
- when creating a TS config in our `eslint-plugin-ghost` dependency, I
only extended the recommended config, which left out a lot of
stylistic things we used to enforce in JS
- this fixes that by bumping the dependency to a version which extends
those shared configs, and fixes all the code that currently goes
against those rules
refs https://github.com/TryGhost/Arch/issues/86
- When PostEditedEvent data contains no visible changes we can skip the matching collections update process alltogether. Each call to `updatePostInMatchingCollections` creates a transaction in addition to fetching all collections. There's no need to process anything when there are no relevant changes in the post edit!
refs https://github.com/TryGhost/Arch/issues/82
- Collections logs are too verbose causing noise.
- Moved some of the logs to use "debug" for now and made summarized logs for the information that we still need while collections code is actively monitored. The event info logs can be removed once we are passed the active phase of rolling out the collections feature
refs https://github.com/TryGhost/Arch/issues/77
- During initial development we have missed to support collections update when tags are added to posts in bulk. It's especially valid usecase since we can define automatic collection with a filter containing not yet existing tags.
refs https://github.com/TryGhost/Arch/issues/47
This ensures that we only have collections which have a valid filter in terms of
- Valid NQL string
- Uses only properties which are valid to filter on
- Only has an empty filter in the case of the "latest" collection
refs https://github.com/TryGhost/Arch/issues/16
- Without an extra await in the update function the passed in transaction would complete before all updates had a chance to run within this transaction.
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkFeaturedEvent/PostsBulkUnfeaturedEvent the collections having a featured filter should update the posts belonging to them.
refs https://github.com/TryGhost/Arch/issues/16
- When posts produce PostsBulkUnpublishedEvent the collections having a published_at filter should update the posts belonging to them
refs https://github.com/TryGhost/Arch/issues/16
- When the bulk destroy is done on posts Collections need to know about the update and remove the stored posts from collections.
refs https://github.com/TryGhost/DevOps/issues/50
- we should default to keeping the rule on and so I've excluded lines
that currently use `any` to avoid the need to go and fix them all up
closes https://github.com/TryGhost/Arch/issues/62
Because there are many ways in which filters can rely on tags, we will just
recalculate all automatic collections for now, rather than attempting to do
optimised updates.
The PostRepository type was using `any` (an anti pattern) rather than
`PostCollection`, and we had optional properties, which are not really
optional. This cleans up the types and updates the tests alongside them.
refs https://github.com/TryGhost/DevOps/issues/50
- `react-app` comes from `eslint-config-react-app`, which is a CRA package
- we're moving away from that so this commit switches the linting over
to a more recently updated plugin
- once that was removed, we started using a newer version of
`@typescript-eslint/eslint-plugin`, so there were plenty of
updates/exemptions to make
refs https://github.com/TryGhost/Arch/issues/60
This will be used to update collections when a tag is deleted. Like the Post
events this should not be in the collections package, instead we should have
these as part of the tags and posts packages. These packages don't exist right
now, so I'm following the existing pattern.
refs https://github.com/TryGhost/DevOps/issues/50
- this switches the .eslint configs from `node` to `ts`, which is a new
config to support eslint for TypeScript
- also makes minor changes to adhere to these new rules
refs https://github.com/TryGhost/Arch/issues/46
- Similarly to post filters, collection filters now support both 'tag' and 'tags' nql filter keys when defining a filter for related tag slugs. For example, both `tag:avocado` and `tags:avocado` would both be valid collection filters that would filter by the same 'slug' property of the tags assigned to a post.
- Along with these changes had to rework the tags property of the collection posts to match the shape used in post resources. Moved from:
`tags: ['bacon', 'broc']`
to
`tags:[{slug: 'bacon'}, {slug: 'broc'}]`
refs https://github.com/TryGhost/Arch/issues/16
- Some of the methods became unused due to moving the posts handling out of the collections service and cleaning up the event handling system.
