add(django-permission-cohort-postgres): minimal sample for keploy/integrations e2e lane

[AkashKumar7902]

add(django-permission-cohort-postgres): minimal sample for keploy/integrations e2e lane

TL;DR

Adds a tiny Django sample (django-permission-cohort-postgres/) that fires SELECT django_content_type WHERE app_label=$1 AND model=$2 on every request. The keploy/integrations e2e lane in keploy/integrations#167 clones this sample to regress the postgres-v3 session-fallback lifetime-gate fix that surfaced as the doccano CI failure (keploy/enterprise#1952).

What the sample does

Two endpoints, both deliberately minimal:

Path	Effect
GET /health/	{"status":"ok"} — used as wait-for-app gate
GET /lookup/<app_label>/<model>/	Calls ContentType.objects.clear_cache() then ContentType.objects.get(app_label=..., model=...) and returns the row

clear_cache() before the lookup forces every request to actually hit the database, so the SQL — SELECT django_content_type WHERE app_label=$1 AND model=$2 LIMIT 21 — fires on every call. That query is what pgmatch.Classify tags class: APP, which DeriveLifetime then maps to LifetimePerTest. That tagging is the precondition for the bug the integrations PR fixes.

What's deliberately NOT in the sample

• No admin
• No DRF / token / session auth
• No static files, no templates, no signal handlers, no celery
• No migrations beyond Django's stock contenttypes / auth tables (those are exactly what the lookup hits)
• CONN_MAX_AGE=0 (default) — fresh connection per request, so the per-request DB call sequence is deterministic across record and replay

The sample is small on purpose so that the failing query is the only DB traffic that matters at replay time. Anything bigger would dilute the regression target.

How to run it standalone

docker compose up
curl http://localhost:8080/health/                            # → {"status":"ok"}
curl http://localhost:8080/lookup/auth/user/                  # → {"id":1,"app_label":"auth","model":"user"}
curl http://localhost:8080/lookup/contenttypes/contenttype/   # → {"id":...,"app_label":"contenttypes","model":"contenttype"}

How keploy/integrations consumes it

The integrations lane (keploy/integrations:.woodpecker/django-permission-cohort-postgres.yml) has a checkout-samples step that runs:

git clone --depth 1 --branch add/django-permission-cohort-postgres \
  https://github.com/keploy/samples-python.git samples-python

The --branch pin will be dropped in a follow-up commit on the integrations branch once this PR merges to main.

The lane's driver script (keploy/integrations:.ci/scripts/python/django-permission-cohort-postgres/docker.sh) reads SAMPLE_SRC_DIR=$WORKSPACE/samples-python/django-permission-cohort-postgres, copies the sample into a per-run staging dir, overlays the agent-side Dockerfile.v3agent + exerciser.sh on top, and runs keploy record + keploy test across the three-binary matrix (record-build-replay-build / record-latest-replay-build / record-build-replay-latest).

Why a new sample rather than reusing django-postgres/

django-postgres/ is a CRUD-shaped user-data app that exercises Django's ORM but doesn't naturally hit django_content_type (no permission framework, no generic relations, no admin in its request path). The bug being regressed is specifically about the ContentType lookup pattern — same shape as the doccano failure that motivated it — so the sample is purpose-built for that. Adding it as a sibling rather than re-fitting django-postgres/ keeps both samples narrowly-scoped and avoids regressing whatever django-postgres/ is currently used for.

Test plan

• Standalone docker compose up boots cleanly and responds 200 to /health/ and /lookup/auth/user/
• keploy/integrations#167 lane (depends on this PR's branch) goes green for the record-build-replay-build cell
• record-build-replay-latest cell stays red until the integrations fix releases downstream — that asymmetry is the bug-existence signal, called out in the lane's .yml header comment

References

• keploy/integrations#167 — the integrations PR that consumes this sample
• keploy/enterprise#1952 — RCA of the bug being regressed
• keploy/enterprise#1889 — original failing pipeline

[AkashKumar7902]

Sibling PR: keploy/integrations#167 (the postgres-v3 session-fallback fix that needs this sample for its e2e lane). The lane in that PR clones this branch verbatim; once this merges to main, a follow-up commit on the integrations branch will drop the --branch pin.