-
Notifications
You must be signed in to change notification settings - Fork 0
fix: name a remedy that works for an unreadable RELEASES #25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 3 commits
ef225b5
5de0e9f
fa8cc3d
615b69d
fdfa7f5
8a83d12
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -344,8 +344,16 @@ defmodule Castle.Commands do | |
| "not be read, when the system booted. An upgrade from that record reports " <> | ||
| "success and leaves any application whose version changed, but whose code the " <> | ||
| "upgrade does not load, running its old code. Creating the file now would not " <> | ||
| "change the record this node works from. Restart the system: the release " <> | ||
| "creates the file before it starts."} | ||
| "change the record this node works from, so the system has to be restarted. " <> | ||
| "Before restarting, make sure the RELEASES file :release_handler reads is " <> | ||
| "either readable or absent, because the release creates that file only when it " <> | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When this file is permission-readable but contains malformed Erlang terms, AGENTS.md reference: AGENTS.md:L440-L446 Useful? React with 👍 / 👎. |
||
| "is absent - an unreadable one left in place is stepped over on every start " <> | ||
| "and the system comes back on the same synthesised record. Absent, or " <> | ||
| "readable, is what a restart needs. That file is releases/RELEASES under the " <> | ||
| "release root unless RELDIR or the sasl releases_dir parameter points " <> | ||
| "elsewhere; where one of those does, the release creates a file at the root " <> | ||
| "that the handler will not read, so the one it does read has to be put there " <> | ||
| "and made readable by hand."} | ||
|
|
||
| nil -> | ||
| {:error, "#{refusal}: no release is running."} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When
RELDIRor{sasl, releases_dir}relocates the handler's records, this release note still says that an absent root-relativereleases/RELEASESmakes a restart sufficient; the release hook creates that root file, but the handler continues reading the relocated path and synthesises another record. Although the command text now handles this override, the user-facing release note preserves the same incorrect remedy and should identify the configured handler file or scope the claim to default Mix deployments.AGENTS.md reference: AGENTS.md:L460-L468
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in
615b69d. You are right, and it is the same correction I had just made to the command text and toAGENTS.mdwhile leaving the note an operator actually reads still saying the wrong thing — the third time in this series that the fix landed in one place and not its restatement, which is the argument for theCastle.Deployment.root_dir/0single-home convention rather than against it.The note now identifies the file instead of assuming it:
releases/RELEASESunder the release root unlessRELDIRor thesaslreleases_dirparameter points elsewhere, and where one of those does, that a restart cannot fix it alone because the release creates the root file the handler will not read. It points at #23 for Castle following the overrides itself.I also swept both documents for other unqualified uses. The remaining mentions describe mechanism — what the handler reads at startup, what an unpack writes back — rather than prescribing a remedy, and the
make_releases/0entry was already qualified in the commit before this one.mix precommitgreen, 112 tests.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in
fdfa7f5. Correct —init/1reads it withfile:consult/1, so malformed terms fail exactly as permissions do, and the hook leaves an existing file alone whatever is in it. "Readable" would have sent an operator with a corruptRELEASESround the same loop the message exists to end.The condition is now absent, or consultable, and the message says why permissions are not the whole of it. Sweeping for the same wording turned up the record-check entry higher in the release note, which still described the cause as the file "not being there" and the remedy as a bare restart; both corrected.
This is the fourth narrowing of this one sentence, and each has been a real defect rather than a rewording, so worth naming the pattern: every version stated a condition that was sufficient for the case I had in mind and not necessary in general — restart, then absent-or-present, then readable. "Consultable by
:release_handler" is the first one phrased as what the handler actually requires rather than as what I expected to have gone wrong.mix precommitgreen, 112 tests.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right on the mechanism again —
init/1accepts only{ok, [Term]}, so two valid terms consult fine and are still rejected. Fixed in8a83d12, and fixed differently from the previous four, because the series itself was the signal.Each version named a property of the file, each was necessary and not sufficient, and each admitted a narrower counterexample: restart → present-but-unreadable; absent-or-present → created readably after boot; readable → malformed terms; consultable → two valid terms. There was no reason to expect that to stop, and the underlying error was mine rather than incremental: I kept stating the condition I expected to have gone wrong instead of the condition the handler imposes.
So the message now asks for a file
:release_handleraccepts, and says explicitly that present, readable and parsing are each necessary and none sufficient. That cannot be narrowed again, because it claims no mechanism — and it is the more useful thing to tell an operator anyway, since the handler is what has to take the file.AGENTS.mdrecords the whole series and says not to substitute whichever internal criterion is current, that being the move that was wrong five times.mix precommitgreen, 112 tests.