custom_slug boundary lengths (exactly 3 or 32 chars) are wrongly rejected

Nobody has started this yet — be first.

Business impact

SLUG_MIN_LEN = 3 and SLUG_MAX_LEN = 32 are the documented, advertised bounds for a custom slug. A user who picks a slug at exactly one of those boundaries -- a short, memorable 3-letter brand tag like "ibm", or a slug padded out to exactly the max length -- gets a 400 telling them their perfectly valid input is invalid. This is a classic "off-by-one that generates support tickets": nothing crashes, nothing corrupts data, but every user who happens to land exactly on a boundary the API itself claims to allow gets bounced, and will not understand why.

Problem

_validate_custom_slug checks if not (SLUG_MIN_LEN < len(slug) < SLUG_MAX_LEN). Both comparisons are strict (<), which excludes the boundary values themselves.

Current behavior

A slug of exactly 3 characters or exactly 32 characters fails this check and the API returns 400, even though the endpoint's own error message says "must be between 3 and 32 characters."

Expected behavior

A custom_slug of exactly SLUG_MIN_LEN (3) or exactly SLUG_MAX_LEN (32) characters is accepted (201), matching what SLUG_MIN_LEN/SLUG_MAX_LEN are documented to mean.

Steps to reproduce

curl -X POST http://localhost:5000/api/urls -H "Content-Type: application/json" -d '{"target_url": "https://example.com", "custom_slug": "abc"}'
Observe: 400 {"error": "custom_slug must be between 3 and 32 characters"}.
'abc' is exactly 3 characters -- it should be accepted.

Why this matters

SLUG_MIN_LEN/SLUG_MAX_LEN are named as inclusive bounds ("must be between 3 and 32 characters"), the plain-English reading of the error message the code itself returns on rejection. A range check whose comparison operators do not match the semantics implied by its own error message is a classic boundary bug -- invisible in almost every manual test (nobody tries exactly the edge value first) and only shows up once real user input starts hitting the edges.

Suggested approach

Compare what the error message says ("between 3 and 32 characters", inclusive by normal English usage) against what the comparison operators in the if actually check. Fix the operators to match the stated semantics, not the other way around.

Acceptance criteria

A custom_slug of exactly 3 characters is accepted
A custom_slug of exactly 32 characters is accepted
A custom_slug of 2 characters is still rejected (400)
A custom_slug of 33 characters is still rejected (400)

Verification

pytest practice_tickets/tests/test_ticket_02_custom_slug_boundary.py -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b fix/custom-slug-boundary

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/custom-slug-boundary

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

URL Shortener with Click Analytics

A production-shaped Flask URL shortener: app-factory pattern, Blueprints, Flask-SQLAlchemy, and a real Redis cache-aside layer in front of Postgres, with per-link click analytics.

Fork on GitHub

Download

Setup

URL Shortener with Click Analytics

git clone <your-fork>
cd FlaskDevTraining/url_shortener_analytics
cp .env.example .env
docker compose up --build   # Postgres + Redis + the Flask app (dev server, debug + reload on)

Migrations run automatically on container startup (see ). Once it is up: