eb1369ce Added tests pinning what a host limit does to a site
Limits are about to be replaced, and nothing here proved they worked. Every
existing test replaces the limit service with stubs and then checks that Ghost
called them, which stays true however the limits are implemented underneath,
including when they are not implemented at all.
These configure limits the way a host does and assert what a caller receives.
All four kinds refusing and allowing: a feature switched off, a count reached, a
value not on a list, and an allowance for a billing period. The numbers a counted
limit puts in its message. The block handed to the browser so it can gate the
same way. The shape an integration parses, which is not the shape it looks like:
the limit's own sentence arrives in the error's context while the message carries
the endpoint's generic wording.
Then the ones nobody has written down. A limit this build has never heard of is
ignored. A known limit spelled in another case loads with none of its settings. A
periodic limit with no billing period to count against is dropped entirely, so a
site that is paying for that limit is not actually held to it. Each of those
leaves a site less limited than its host asked for, silently.
The only thing stubbed is the call that would leave the process to reach Stripe.
Setting a limit is otherwise setting configuration and nothing else: the one
wrinkle, that limits are read during boot and must be re-read when a test changes
them, is now behind a single helper rather than a reason to reach for a stub. The
browser test fixture takes any host setting rather than the handful somebody
happened to need.
ref https://linear.app/ghost/issue/BER-3797 f21c5352 Added tests pinning what a host limit does to a site
Limits are about to be replaced, and nothing here proved they worked. Every
existing test replaces the limit service with stubs and then checks that Ghost
called them, which stays true however the limits are implemented underneath,
including when they are not implemented at all.
These configure limits the way a host does and assert what a caller receives.
All four kinds refusing and allowing: a feature switched off, a count reached, a
value not on a list, and an allowance for a billing period. The numbers a counted
limit puts in its message. The block handed to the browser so it can gate the
same way. The shape an integration parses, which is not the shape it looks like:
the limit's own sentence arrives in the error's context while the message carries
the endpoint's generic wording.
Then the ones nobody has written down. A limit this build has never heard of is
ignored. A known limit spelled in another case loads with none of its settings. A
periodic limit with no billing period to count against is dropped entirely, so a
site that is paying for that limit is not actually held to it. Each of those
leaves a site less limited than its host asked for, silently.
The only thing stubbed is the call that would leave the process to reach Stripe.
Setting a limit is otherwise setting configuration and nothing else: the one
wrinkle, that limits are read during boot and must be re-read when a test changes
them, is now behind a single helper rather than a reason to reach for a stub. The
browser test fixture takes any host setting rather than the handful somebody
happened to need.
ref https://linear.app/ghost/issue/BER-3797 e3aaccef Added tests pinning what a host limit does to a site
Limits are about to be replaced, and nothing here proved they worked. Every
existing test replaces the limit service with stubs and then checks that Ghost
called them, which stays true however the limits are implemented underneath,
including when they are not implemented at all.
These configure limits the way a host does and assert what a caller receives.
All four kinds refusing and allowing: a feature switched off, a count reached, a
value not on a list, and an allowance for a billing period. The numbers a counted
limit puts in its message. The block handed to the browser so it can gate the
same way. The shape an integration parses, which is not the shape it looks like:
the limit's own sentence arrives in the error's context while the message carries
the endpoint's generic wording.
Then the ones nobody has written down. A limit this build has never heard of is
ignored. A known limit spelled in another case loads with none of its settings. A
periodic limit with no billing period to count against is dropped entirely, so a
site that is paying for that limit is not actually held to it. Each of those
leaves a site less limited than its host asked for, silently.
The only thing stubbed is the call that would leave the process to reach Stripe.
Setting a limit is otherwise setting configuration and nothing else: the one
wrinkle, that limits are read during boot and must be re-read when a test changes
them, is now behind a single helper rather than a reason to reach for a stub. The
browser test fixture takes any host setting rather than the handful somebody
happened to need.
ref https://linear.app/ghost/issue/BER-3797 161897b9 Added tests pinning what a host limit does to a site
Limits are about to be replaced, and nothing here proved they worked. Every
existing test replaces the limit service with stubs and then checks that Ghost
called them, which stays true however the limits are implemented underneath,
including when they are not implemented at all.
These configure limits the way a host does and assert what a caller receives.
All four kinds refusing and allowing: a feature switched off, a count reached, a
value not on a list, and an allowance for a billing period. The numbers a counted
limit puts in its message. The block handed to the browser so it can gate the
same way. The shape an integration parses, which is not the shape it looks like:
the limit's own sentence arrives in the error's context while the message carries
the endpoint's generic wording.
Then the ones nobody has written down. A limit this build has never heard of is
ignored. A known limit spelled in another case loads with none of its settings. A
periodic limit with no billing period to count against is dropped entirely, so a
site that is paying for that limit is not actually held to it. Each of those
leaves a site less limited than its host asked for, silently.
The only thing stubbed is the call that would leave the process to reach Stripe.
Setting a limit is otherwise setting configuration and nothing else: the one
wrinkle, that limits are read during boot and must be re-read when a test changes
them, is now behind a single helper rather than a reason to reach for a stub. The
browser test fixture takes any host setting rather than the handful somebody
happened to need.
ref https://linear.app/ghost/issue/BER-3797 95305893 Added tests pinning what a host limit does to a site
Limits are about to be replaced, and nothing here proved they worked. Every
existing test replaces the limit service with stubs and then checks that Ghost
called them, which stays true however the limits are implemented underneath,
including when they are not implemented at all.
These configure limits the way a host does and assert what a caller receives.
All four kinds refusing and allowing: a feature switched off, a count reached, a
value not on a list, and an allowance for a billing period. The numbers a counted
limit puts in its message. The block handed to the browser so it can gate the
same way. The shape an integration parses, which is not the shape it looks like:
the limit's own sentence arrives in the error's context while the message carries
the endpoint's generic wording.
Then the ones nobody has written down. A limit this build has never heard of is
ignored. A known limit spelled in another case loads with none of its settings. A
periodic limit with no billing period to count against is dropped entirely, so a
site that is paying for that limit is not actually held to it. Each of those
leaves a site less limited than its host asked for, silently.
The only thing stubbed is the call that would leave the process to reach Stripe.
Setting a limit is otherwise setting configuration and nothing else: the one
wrinkle, that limits are read during boot and must be re-read when a test changes
them, is now behind a single helper rather than a reason to reach for a stub. The
browser test fixture takes any host setting rather than the handful somebody
happened to need.
ref https://linear.app/ghost/issue/BER-3797