MARISSA MOLEJON | OCT2025-1 | Module-Legacy-Code | Sprint 1 | add rebloom feature - #5

Summary

Implements "Rebloom". A user can rebloom another user's bloom; it then appears in the rebloomer's
followers' feeds, clearly attributed to both the original poster and
the rebloomer, with a visible rebloom count.

Design decisions (issue left these open)

Data model: reblooms is a join table referencing the original
bloom by ID, not a content-duplicating copy — consistent with how
follows and hashtags are already modeled in this schema.

Timestamps: the issue explicitly called this out as unclear.
Chose to show both — the original post's timestamp, and the
rebloom's own timestamp — with feed ordering based on whichever is
more recent. This matches familiar retweet-style UX (e.g. seeing an
old post resurface in your feed because someone you follow just
reshared it).

Self-rebloom: blocked, with a clear error message. (Debatable —
happy to revisit if the team prefers allowing it.)

Feed deduplication: if a bloom qualifies for your feed both as an
original post (you follow the author) and as a rebloom (you follow
the rebloomer), it appears once, showing whichever activity is
most recent.

Changes

Schema

• New reblooms table: (id, bloom_id, rebloomer_id, rebloom_timestamp),
  UNIQUE(bloom_id, rebloomer_id) for idempotency.

Backend

• Bloom dataclass: added rebloomer, rebloom_timestamp,
  rebloom_count (all optional/defaulted, so no existing call sites
  needed changes).
• add_rebloom(), get_rebloom_count() in blooms.py.
• get_home_timeline() — replaces the old Python-side
  concatenation-and-sort with a single SQL query, unioning original
  posts and reblooms, deduplicated via DISTINCT ON. (Note: this
  required wrapping the UNION ALL in a subquery, since Postgres
  doesn't allow ORDER BY with expressions directly on a UNION.)
• POST /rebloom endpoint — validates input, 404s on missing bloom,
  400s on self-rebloom, otherwise idempotent.

Frontend

• apiService.rebloom().
• Bloom template gets a rebloom indicator (shown only for reblooms),
  a rebloom button, and a rebloom count (shown only when > 0).
• createBloom() / handleRebloom() wire it all up.
• Minor CSS fix for a layout issue the rebloom count surfaced.

Testing

Backend verified via curl: dedup, idempotency, self-rebloom
rejection, 404 handling, boundary/edge cases.
Frontend verified in-browser via DevTools: found and fixed a real
type-mismatch bug (string vs int) and a real CSS layout bug during
testing — both documented in the commit message with root cause.

Scope / follow-ups worth considering

• No automated tests added (same gap noted on prior PRs in this repo).
• get_rebloom_count() is called once per bloom in a loop inside
  get_home_timeline() - fine at current data volumes, but would be
  worth batching into a single query if this table grows large.
• Un-reblooming (removing a rebloom) isn't implemented; the issue
  didn't request it, but it'd be a natural follow-up.