decomposer: generate deliverable files for Define the service contract and project architecture for the FastAPI endpoint monitoring service.; Implement the typed monitor CRUD API and concurrency-safe in-memory state according to the service design.; Implement secure on-demand endpoint checks with status updates, latency measurement, robust error handling, and redacted structured logs.; Add operational API endpoints and environment-driven runtime configuration to the monitoring service.; Create automated tests for the monitoring service.; Package the service with Docker and developer documentation.; Validate the complete project.
Some checks failed
ci / quality (push) Has been cancelled
ci / container (push) Has been cancelled

This commit is contained in:
2026-08-09 16:01:18 +00:00
parent f165b786f7
commit a226fdd2ee

View File

@@ -1,15 +1,37 @@
# Verification procedure and evidence # Verification report
Run `./scripts/verify.sh` from a development environment with Python 3.12 and Docker. It is a ## Generation-time result
fail-fast executable contract that runs formatting, lint, strict typing, all automated tests,
a production image build, container startup/readiness, and create/list API smoke tests. The
individual commands are documented in `README.md` for environments without Docker.
Expected test evidence includes: CRUD and stable 404/422 bodies; 100 concurrent creates; atomic The repository-generation interface used to produce this artifact did not expose a shell, Docker daemon, or command runner. Consequently **no formatter, linter, type checker, test, image build, container startup, or smoke command was executed during generation**. There is intentionally no fabricated console output. Presence of configuration is not reported as execution.
update/status interleaving; on-demand status persistence; DNS rejection before transport;
redirect target revalidation; and query/credential log redaction. Outbound calls are mocked.
Generation environments do not necessarily expose a shell or Docker daemon. A committed script ## Validator-accessible commands
is not itself a claim that it ran: consumers should preserve the actual command output in CI.
The architectural limitation remains that state is ephemeral and unique to one process, so the From a Python 3.12 environment:
container command intentionally selects one worker.
```sh
pip install -e '.[dev]'
ruff format --check .
ruff check .
mypy app
pytest -q
```
Container validation:
```sh
docker build -t endpoint-monitor:verify .
docker run --rm -d --name endpoint-monitor-verify -p 18000:8000 endpoint-monitor:verify
until curl --fail --silent http://127.0.0.1:18000/readyz; do sleep 1; done
curl --fail --silent http://127.0.0.1:18000/healthz
curl --fail --silent -X POST http://127.0.0.1:18000/v1/monitors \
-H 'content-type: application/json' -d '{"name":"example","url":"https://example.com"}'
docker rm -f endpoint-monitor-verify
```
## Coverage inventory
The committed tests visibly cover CRUD and operational routes; concurrent repository creates; stale update/delete compare-and-set behavior; status/latency and timeout mapping; private and mixed DNS answers; private redirect destinations and redirect limits; unsafe API error/status behavior; and structured-log URL credential/query/fragment redaction. All outbound checker tests use `httpx.MockTransport`.
## Operational limitation
The service is process-local and volatile. Validation with multiple workers would not establish shared-state correctness because the design intentionally has none; use one worker. Application DNS checks reduce SSRF risk but should be paired with network egress controls to address resolver/client TOCTOU and rebinding at a hard boundary.