docs(activation-service): correct the ACTIVATION_AMOUNT guidance - #1110
Open
sameh-farouk wants to merge 1 commit into
Open
docs(activation-service): correct the ACTIVATION_AMOUNT guidance#1110sameh-farouk wants to merge 1 commit into
sameh-farouk wants to merge 1 commit into
Conversation
Two things I got wrong when the variable was first documented. The .env example still said ACTIVATION_AMOUNT=1 while the Helm chart defaults to 0.1. Both are meant to be the recommended starting value, so anyone deploying from the readme with Docker or locally would have funded 1 TFT per activation — ten times the Kubernetes default and ten times what the service actually pays out today. The example is now 0.1. It also claimed the value "defaults to 0.1 when unset", and then a few lines later that it is required and must be set anyway. Both statements were in the same file. bin/www lists ACTIVATION_AMOUNT in REQUIRED_ENV_VARIABLES and refuses to start without it, so the fallback in lib/config.js is unreachable through the normal entrypoint and only applies to callers that bypass it, such as the tests. Said plainly now instead of two ways at once. Also makes it explicit that the unit does not depend on how the service is deployed. The value is read from the environment, so Helm, `docker run -e` and a local .env all take whole TFT. The image itself sets no environment variables, so every deployment supplies all three; the deployment section now shows a docker run invocation rather than telling the reader to configure the variables listed above. Verified: 0.1 resolves to 1000000 base units, 1 to 10000000, and an unset value stops startup with "Missing env variables".
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.
Follow-up to #1105/#1109. Two documentation errors of mine, found while checking whether
ACTIVATION_AMOUNTis chart-specific.The
.envexample contradicted the chartBoth are meant to be the recommended starting value. Anyone deploying from the readme with Docker or locally would have funded ten times the Kubernetes default, and ten times what the service actually pays out today. Example changed to
0.1.It documented a default that cannot happen
The readme said the value "defaults to
0.1when unset", then a few lines later that it "is required, so set it explicitly even though it has a default". Both, in the same file.bin/wwwlistsACTIVATION_AMOUNTinREQUIRED_ENV_VARIABLESand refuses to start without it, so the fallback inlib/config.jsis unreachable through the normal entrypoint — it only applies to callers that bypass it, such as the tests. Confirmed:Now stated once, accurately.
The unit does not depend on the deployment method
Worth making explicit, since it was the question that prompted this.
ACTIVATION_AMOUNTis read straight fromprocess.envinlib/config.js, so it is whole TFT for Helm,docker run -e, and a local.envalike — the unit is a property of the application, not of how it is deployed.The image sets no environment variables of its own (no
ENVorARGin the Dockerfile), so every deployment must supply all three. The deployment section now shows adocker runinvocation instead of telling the reader to "configure the environment variables listed above", and points at the chart for the Kubernetes equivalent.Verification
Lint and unit tests pass. Documentation only — no code changes.
🤖 Generated with Claude Code
https://claude.ai/code/session_011YKJm3zuWdSepriT9KL9zy