fix: make the nest probe guard able to fail - #21
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
services/shared/nest.shruns foursedsplices oversrc/health/health.controller.tsand then verifies them with fourgreps.Three of those verify something; the fourth could not fail.
adapters/nestjs/src/health/health.controller.ts:14— thelive()handler —already returns exactly
{ status: 'ok' };before any splice runs, and thegrepis unanchored, so it matched the shipped file rather than the splice itwas meant to prove.
That
grepguards the splice that replacesthrow new Error('no database is configured for this project')with the successreturn. If that one anchor ever drifted while the other three still matched, no
diewould fire: the generated controller would carry the client field, theprobe and
async ready(), and then still throw on every request. The projectwould ship a readiness endpoint that answers 503 forever, silently, with a
liveness endpoint that answers 200 beside it.
The check now proves the sentinel is gone rather than that a success string is
present — the same shape
services/shared/flask.shuses, sinceflaskhad theidentical hole and it was fixed there first.
services/shared/laravel.shandservices/mongodb/drivers/laravel.shdo not have it:routes/health.phpshipsno liveness route, so their
['status' => 'ok']check has nothing to matchexcept the splice.
Nothing else changes. The splice itself was never broken — this is its alarm.
How it was verified
The negative case first, because a guard is only worth what it catches. Against
a copy of the shipped controller with three of the four splices applied and the
throwdeliberately left in place:diefiresThen the positive case, end to end on both provider branches, since the SQL and
mongodb drivers both source this body:
./scripts/deploy-check.sh nestjs --db postgres./scripts/deploy-check.sh nestjs --db mongodbEach generates a project, builds the image, starts the released stack and gets
200 from
/health/liveand/health/ready.mise run lintand./scaffold lint— cleanmise run test-runner— both lanesChecklist
mise run lintpassesmise run test-runnerpasses