Verification and acceptance
Verification for the two PRs combines focused unit tests, Django checks, linting, and live infrastructure smoke tests.
Automated coverage
The focused subscriber suite covers:
| Area | Verified behavior |
|---|---|
| Topic policy | Webhook list equals green allowlist; excluded topics rejected |
| Parser | All 39 topics normalize and map to the correct table; non-object payload rejected |
| Router | Every allowlisted type has a module handler; slash notation accepted |
| Storage | Event plus snapshot writes, no-ID snapshot skip, deterministic fallback ID, missing configuration error |
| Provisioning | All 13 tables selected; management command passes organization context |
| Header extraction | Shopify attributes, merged headers, raw-body wrapping, inferred source and IDs |
| Ack/nack | Ack after stored failure; nack when failure persistence fails |
| Replay | Success resolves; failed replay backs off; max retry becomes terminal |
| Middleware | Shopify webhook path bypasses global JWT while retaining HMAC verification |
The recorded PR #23 focused run passed 42 subscriber tests. Linting, Django system checks, and migration drift checks also passed.
Recommended verification commands
venv/bin/python -m ruff check subscriber shopify
venv/bin/python -m pytest subscriber/tests schema/tests/test_middleware.py --no-cov
venv/bin/python manage.py makemigrations subscriber --check --dry-run
venv/bin/python manage.py check
Run the repository's complete suite before release as a separate gate:
venv/bin/python -m pytest --no-cov
The historical PR #23 full run reported 212 passing tests and four pre-existing failures in database/tests/test_ask_me_integration.py caused by a list being passed to a numeric database filter. Those failures were outside the Shopify changes and should be re-evaluated against the current branch before release.
The repository's current local virtual environment uses Python 3.9 and emits end-of-support warnings from Google client libraries. CI is configured for Python 3.12; production workers should use a currently supported Python runtime as well.
Live integration scenarios
| Scenario | Infrastructure path | Expected evidence |
|---|---|---|
| Order success | Real Pub/Sub to worker to Supabase | shopify_events and shopify_orders rows |
| Customer database deadlock | Real Pub/Sub, PostgreSQL exception, replay | Pending failure created, then resolved; customer rows persisted |
| Malformed payload | Real Pub/Sub, parser failure | Pending failure retained with retry metadata |
| Target database unavailable | Real Pub/Sub, invalid connection, restored connection, replay | Operational error retained, then resolved; product rows persisted |
| Direct signed webhook | HTTPS Django endpoint | 200 EVENT_RECEIVED and one application ShopifyEvent row |
Release acceptance criteria
- Docusaurus production build succeeds with broken links treated as errors.
- Focused subscriber and middleware tests pass.
- Subscriber migration is applied to the application database.
- Each onboarded client passes 13-table provisioning.
- Multi-client workers do not set the global Supabase URL override.
- Service account credentials resolve through ADC and have least-privilege Pub/Sub access.
- One success event and one controlled failure/replay are observed in the target environment.
- A scheduler invokes
retry_failed_eventswithout overlapping executions. - Monitoring includes pending age, terminal failure count, subscriber liveness, and Pub/Sub backlog.
Residual risk
Passing tests do not close the current design gaps: field-level parsers remain incomplete outside customer create/update/delete, missing connections are acknowledged without durable capture, retries are not leased for concurrency, and there is no retention policy. These items should remain visible in production readiness review.