DataTalksClub / DataTalksClub/website
A read-only prod script should not offer a production write opt-in
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
scripts/prod/target's add_target_arguments is shared by every scripts/prod
entry point, so a read-only tool inherits the writer's operator surface.
Found during #323's acceptance, on scripts/prod/sync_content_verify.py, which
has no write path of any kind — proven during verification by running it on a
read-only filesystem:
sync_content_verify.py: error: writing to the website-production database
requires --allow-production-write website-production
The tool is telling an operator that reading requires a production write
opt-in.
There is no data risk here — the flag guards a write path this script does not
have. The cost is to the guard itself. scripts/prod/target's own docstring
rests on a two-flag property: --deployment-target NAME selects a deployed
database and --allow-production-write NAME must name the same one, so that a
production write is always two deliberate acts. Routinising the second flag on
tools where it is meaningless trains operators to add it reflexively, which is
exactly the habit the two-flag design exists to prevent — and the next tool that
does write is the one that pays.
Scope: let a read-only entry point declare itself so, and not be offered a
production write opt-in. sync_content_verify.py is the first such tool; the
drift check family (#323) and any future reporter will be more.
Grooming should settle whether "read-only" is declared per module (alongside the
existing SYNC_MODEL / BOOTSTRAPS_EMPTY_DATABASE conventions that
scripts/tests/test_prod_conventions.py already checks) or inferred, and
whether the declaration should be enforced — a module claiming read-only while
importing a writer is the failure worth catching.
This touches every scripts/prod entry point, so it was explicitly kept out of
#323.
Refs #310
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read scripts/prod/target and sync_content_verify.py first, then inspect the conventions checked by scripts/tests/test_prod_conventions.py. Determine how a read-only entry point should declare itself and whether that declaration is enforced. Done means read-only tools no longer offer the production-write opt-in while the shared scripts/prod entry points retain their safeguards.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- devops, tooling
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100