- As of Ghost 5.0 we only use the V2 version of jsonErrorRenderer
- Removed the old one, and renamed the V2 to not have a suffix any more
- Added 100% coverage to tests whilst here
- trying to call new RequestNotAcceptableError with a variable triggers a lint warning in newer versions of eslint-plugin-ghost
- this workaround is worth it for the safety of not allowing single strings to be passed in!
- this middleware block is used in v4 but not in v5
- we want to remove it and then rename handleJSONResponseV2 so that we have one single consistent error handling block
refs https://github.com/TryGhost/Toolbox/issues/292
- There's a need to distinguish different types of RequestNotAcceptableError erros by their code. The code is also having an instructional name to give it more explicit utility (nice clue for a developer seeing the error)
refs https://github.com/TryGhost/Toolbox/issues/280
- When an outdated client receives a 404 as a response there's no clear way to act on it. Plain 404 says nothing about need to update.
- In such cases the resourceNotFound handler should return a 406 error indicating the Ghost instance needs an update.
refs https://github.com/TryGhost/Toolbox/issues/280
- When an outdated client receives a 404 as a response there's no clear way to act on it. Plain 404 says nothing about need to update.
- In such cases the resourceNotFound handler should return a 406 error indicating the client need to update.
- in the event we get an unknown error bubble up, we don't handle the
templating on the error name
- `@tryghost/tpl` throws an error because we pass an undefined string:
`Cannot read properties of undefined (reading 'replace')`
- this commit adds handling to fallback to a different user message in
that event so we don't cause a 500 error
no issue
Change to error handling caused all theme errors to be reported in Sentry, this fix (and a respective fix in Ghost) allows the error to be prepared for sentry before replacing the stack
refs: https://github.com/TryGhost/Team/issues/1369
If we prepare the error for users to view before using Sentry, then the error passed to Sentry will have the stack trace removed for production environments.
@tryghost/errors@1.2.5 also made it so that the error is not mutated, but cloned and a new one is returned.
