You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The repository still carries configuration and documentation written for a hosted instance that is being shut down, and it should be removed or rewritten once its replacement exists, not before. The old instance ran under the previous GitHub organisation and is being retired as part of the move to civictechdc. A new deployment is planned to replace it, and until that lands these files are the only written description of how the service was actually run, so deleting them now would destroy the reference needed to stand the new one up.
This issue is the list of what to revisit at cutover. Each item is inert today and none of it blocks anything.
Four artifacts, all present on develop:
web/webapp/.htaccess contains Apache RewriteRule directives that force HTTPS. Two things make it removable rather than merely stale. It was already unused while the old site was running, because Apache proxied every request to uvicorn rather than processing the directory, and the application serves it to the public. web/app.py mounts web/webapp/ as StaticFiles at /, so the file is reachable at /.htaccess on any deployment of this app.
The redeploy line in docs/web-compare.md: After deploy: `git pull && uv sync --no-dev && sudo systemctl restart deltatrack` (see private deployment runbook). Both the command and the pointer describe the retired host. The pointer is one of the two references tracked by Production deployment and recovery instructions are only accessible to one maintainer #546 (the production deployment and recovery instructions exist only on one maintainer's machine).
The production rate-limit guidance in docs/web-compare.md, which states that production runs a single uvicorn worker and warns that putting a CDN in front of Apache breaks the rate-limit key, because _rate_limit_key reads the last X-Forwarded-For entry and a CDN edge address collapses every client into one shared bucket. The topology it describes will not exist, but the trap is real and applies to any replacement that fronts the app with a proxy or CDN. This one wants rewriting against the new topology rather than deleting.
force_https_behind_proxy in web/app.py, an HTTP to HTTPS redirect middleware that only does anything when a proxy forwards X-Forwarded-Proto: http or port 80. Whether to keep it depends on how the new deployment terminates TLS. It is host-agnostic and harmless, so the default is to keep it.
Three mentions of the old hostname also survive under docs/research/. Those are dated analyses rather than current instructions, so the reasonable default is to leave them; they are listed here only so the sweep is complete.
How it surfaced
Found while repointing the repository's references after the organisation transfer. The hostname and organisation rename was done then; these four are the artifacts that outlive a rename because they describe a deployment rather than a name.
Verified on branch worktree-repo-ownership-civictechdc @ 977e9345, which is develop plus the rename work and touches none of the four files above. The public exposure in item 1 was checked against the application rather than the old host, so the result does not depend on that host still being up:
>>> TestClient(app).get('/.htaccess')
status: 200
first line: # DeltaTrack public site — force HTTPS for all requests.
Why it matters
It unblocks nothing on its own, which is the point of filing it rather than doing it. The risk being managed is the opposite one: a future contributor reads systemctl restart deltatrack or the single-worker rate-limit note as current fact and acts on a topology that no longer exists. docs/web-compare.md now labels these as describing the outgoing setup, which holds the line until the replacement is real, and this issue is the reminder to finish the job at that point.
Item 1 is the only one with any present-day consequence, and it is small: a dead Apache config file is publicly readable on whatever is serving the app. It discloses no credential. It can reasonably be removed ahead of the rest.
Related work
The new deployment likely touches, and may resolve, several existing issues. Worth reading together rather than in isolation:
Open decision: DeltaTrack delivery channel(s) #112 (the open decision on DeltaTrack's delivery channels) governs whether a hosted upload path should exist at all, since one is an exception to local-only processing under ADR 0011 (docs/decisions/0011-local-only-processing.md).
#546 argues its case partly by citing docs/https-redirect.md as an existing example of deployment configuration the project publishes rather than keeps private. That file has since been deleted, because it documented the retired host's Apache and ISPConfig setup specifically and does not survive it. The argument in #546 still stands on its other example, but the reference itself is now stale.
Unverified
Whether the new deployment will terminate TLS at a proxy at all, which is what decides item 4. No replacement topology has been chosen yet.
What needs doing
The repository still carries configuration and documentation written for a hosted instance that is being shut down, and it should be removed or rewritten once its replacement exists, not before. The old instance ran under the previous GitHub organisation and is being retired as part of the move to
civictechdc. A new deployment is planned to replace it, and until that lands these files are the only written description of how the service was actually run, so deleting them now would destroy the reference needed to stand the new one up.This issue is the list of what to revisit at cutover. Each item is inert today and none of it blocks anything.
Four artifacts, all present on
develop:web/webapp/.htaccesscontains ApacheRewriteRuledirectives that force HTTPS. Two things make it removable rather than merely stale. It was already unused while the old site was running, because Apache proxied every request to uvicorn rather than processing the directory, and the application serves it to the public.web/app.pymountsweb/webapp/asStaticFilesat/, so the file is reachable at/.htaccesson any deployment of this app.The redeploy line in
docs/web-compare.md:After deploy: `git pull && uv sync --no-dev && sudo systemctl restart deltatrack` (see private deployment runbook).Both the command and the pointer describe the retired host. The pointer is one of the two references tracked by Production deployment and recovery instructions are only accessible to one maintainer #546 (the production deployment and recovery instructions exist only on one maintainer's machine).The production rate-limit guidance in
docs/web-compare.md, which states that production runs a single uvicorn worker and warns that putting a CDN in front of Apache breaks the rate-limit key, because_rate_limit_keyreads the lastX-Forwarded-Forentry and a CDN edge address collapses every client into one shared bucket. The topology it describes will not exist, but the trap is real and applies to any replacement that fronts the app with a proxy or CDN. This one wants rewriting against the new topology rather than deleting.force_https_behind_proxyinweb/app.py, an HTTP to HTTPS redirect middleware that only does anything when a proxy forwardsX-Forwarded-Proto: httpor port 80. Whether to keep it depends on how the new deployment terminates TLS. It is host-agnostic and harmless, so the default is to keep it.Three mentions of the old hostname also survive under
docs/research/. Those are dated analyses rather than current instructions, so the reasonable default is to leave them; they are listed here only so the sweep is complete.How it surfaced
Found while repointing the repository's references after the organisation transfer. The hostname and organisation rename was done then; these four are the artifacts that outlive a rename because they describe a deployment rather than a name.
Verified on branch
worktree-repo-ownership-civictechdc@977e9345, which isdevelopplus the rename work and touches none of the four files above. The public exposure in item 1 was checked against the application rather than the old host, so the result does not depend on that host still being up:Why it matters
It unblocks nothing on its own, which is the point of filing it rather than doing it. The risk being managed is the opposite one: a future contributor reads
systemctl restart deltatrackor the single-worker rate-limit note as current fact and acts on a topology that no longer exists.docs/web-compare.mdnow labels these as describing the outgoing setup, which holds the line until the replacement is real, and this issue is the reminder to finish the job at that point.Item 1 is the only one with any present-day consequence, and it is small: a dead Apache config file is publicly readable on whatever is serving the app. It discloses no credential. It can reasonably be removed ahead of the rest.
Related work
The new deployment likely touches, and may resolve, several existing issues. Worth reading together rather than in isolation:
docs/decisions/0011-local-only-processing.md).Note for #546
#546 argues its case partly by citing
docs/https-redirect.mdas an existing example of deployment configuration the project publishes rather than keeps private. That file has since been deleted, because it documented the retired host's Apache and ISPConfig setup specifically and does not survive it. The argument in #546 still stands on its other example, but the reference itself is now stale.Unverified
Whether the new deployment will terminate TLS at a proxy at all, which is what decides item 4. No replacement topology has been chosen yet.
Refs #112, #546, #400, #545, #555