GLM 5.3

Minimal Meeting Room Reservation API

POST /rooms/{room_id}/reservations
Body: { "start": "2024-06-01T10:00:00Z",
        "end":   "2024-06-01T11:00:00Z" }

Responses:
  201 Created  → { "reservation_id": "...", "status": "confirmed" }
  409 Conflict  → { "error": "room already booked for that interval" }

Preventing Overlapping Bookings

Use a database transaction with a lock, not application-level checks:

BEGIN;
  SELECT * FROM reservations
  WHERE room_id = :room AND start < :end AND end > :start
  FOR UPDATE;            -- locks matching rows (and gaps via predicate locks
                           -- in SERIALIZABLE mode)
  INSERT INTO reservations (room_id, start, end, user_id)
  VALUES (:room, :start, :end, :user);
COMMIT;

How this handles two simultaneous requests:

1. Atomicity: Check-and-insert happens in one transaction; a request can't be validated against stale data.
2. Locking: With isolation level SERIALIZABLE (or FOR UPDATE), the second transaction's overlapping check blocks or the insert fails at commit time, so only one transaction succeeds.
3. Single winner: The loser gets a rollback and returns 409 Conflict; the client may retry with a different time.

Alternative: enforce uniqueness via a constraint on booked 15-minute slots (inserting one row per slot, unique index on (room_id, slot)), turning races into simple duplicate-key errors.

Making Your First Pull Request

Before requesting review, check:

1. Your branch is up to date

git fetch origin
git rebase origin/main   # or your target branch

2. Your changes pass local checks

git diff --stat          # confirm only intended files changed
npm test                  # or your project's test command

3. Your commits are clean

• Squash "fix typo" / "WIP" commits where possible
• Use clear commit messages

4. The PR itself is complete

• Descriptive title (not just "fix")
• Description covering what changed and why
• Screenshots for UI changes
• Notes on anything reviewers should scrutinize

5. You've reviewed it yourself first Read the full diff as if someone else wrote it. You'll catch stray console.log statements, commented-out code, and debugging artifacts before anyone else does.

Quick self-check list

• Tests pass locally
• No unrelated changes in the diff
• Rebased onto latest target branch
• Description explains the "why"
• You reviewed your own diff

Small, focused PRs get reviewed faster. If yours touches five unrelated things, consider splitting it.

Observed rates: A = 8/100 = 8%, B = 10/100 = 10%, a 25% relative lift. But with such small samples, randomness alone easily produces gaps this size.

from scipy import stats
import math

# Two-proportion test
conv_a, n_a = 8, 100
conv_b, n_b = 10, 100

p_pool = (conv_a + conv_b) / (n_a + n_b)
se = math.sqrt(p_pool * (1 - p_pool) * (1/n_a + 1/n_b))
z = (conv_b/n_b - conv_a/n_a) / se
p_value = 2 * (1 - stats.norm.cdf(abs(z)))
print(f"z = {z:.3f}, p = {p_value:.3f}")

This gives p ≈ 0.62 — far from significance. The 95% confidence interval for the difference roughly spans −5 to +9 percentage points, which includes B being worse than A.

In short: 10% vs 8% is a noisy estimate, not a finding. Sampling just 200 visitors means each purchase swings the rate by a full percentage point. To declare a winner, we'd need a pre-registered sample size (likely thousands of visitors per arm, depending on baseline rate and minimum detectable effect), and ideally Bayesian estimates showing a high probability that B > A. Stopping early on a noisy lead risks declaring a false winner.