Skip to content

ZA | 25-SDC-JULY | Luke Manyamazi | Sprint 1 | Extra Long Bloom#52

Closed
Luke-Manyamazi wants to merge 0 commit into
CodeYourFuture:mainfrom
Luke-Manyamazi:BR-Extra-long-bloom
Closed

ZA | 25-SDC-JULY | Luke Manyamazi | Sprint 1 | Extra Long Bloom#52
Luke-Manyamazi wants to merge 0 commit into
CodeYourFuture:mainfrom
Luke-Manyamazi:BR-Extra-long-bloom

Conversation

@Luke-Manyamazi

@Luke-Manyamazi Luke-Manyamazi commented Nov 11, 2025

Copy link
Copy Markdown

Learners, PR Template

Self checklist

  • I have titled my PR with Region | Cohort | FirstName LastName | Sprint | Assignment Title
  • My changes meet the requirements of the task
  • I have tested my changes
  • My changes follow the style guide

Changelist

Added validation in send_bloom() route to reject content exceeding 280 characters.
Updated bloom.py model to handle content truncation safely when inserting new blooms.
Added database cleanup step (SQL) to truncate existing blooms longer than 280 characters.
Improved error response messages for better feedback when validation fails.

Questions

None

@Luke-Manyamazi Luke-Manyamazi added 📅 Sprint 1 Assigned during Sprint 1 of this module Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. Module-Legacy-Code The name of the module. labels Nov 11, 2025

@illicitonion illicitonion left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This generally looks good! One extra note I have is that the number 280 is appearing in a lot of places in this code, so if you wanted to change it to 300 you'd need to change it in a lot of places - can you think how to reduce this duplication?

Comment thread backend/data/blooms.py Outdated
Comment on lines +21 to +22
if len(content) > 280:
content = content[:280] # truncate to 280 characters

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automatically truncating works (and you have endpoint-layer checks to make sure we shouldn't get here), but it's not clear whether at the DB layer we should truncate or reject - what do you think the trade-offs are here?

@illicitonion illicitonion added Reviewed Volunteer to add when completing a review with trainee action still to take. and removed Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. labels Jan 20, 2026
@Luke-Manyamazi

Copy link
Copy Markdown
Author

Good point Daniel, I have removed the hardcoded number and introduced Bloom.MAX_CONTENT_LENGTH, so the limit is defined in one place and is easier to change.

On truncation vs rejection - truncating is convenient but risks silent data loss. I’ve opted to reject oversized content at the model layer, with endpoint validation providing user-friendly errors, so behaviour stays explicit and data integrity is preserved.

@Luke-Manyamazi Luke-Manyamazi added the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Feb 14, 2026

@illicitonion illicitonion left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good thoughts on truncation vs rejection! I left a few more comments.

Comment thread backend/data/blooms.py Outdated


def add_bloom(*, sender: User, content: str) -> Bloom:
# Enforce 280-character limit

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is yet another thing that can get out of date :D

Suggested change
# Enforce 280-character limit
# Enforce character limit

Comment thread backend/data/blooms.py Outdated

def add_bloom(*, sender: User, content: str) -> Bloom:
# Enforce 280-character limit
content = content.strip()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you choosing to strip whitespace here? Is a bloom of 5000 space characters more valid than a bloom of 5000 letters?

Comment thread backend/endpoints.py Outdated
return validation_error

# 2. Data Extraction and Cleaning
content = request.json.get("content", "").strip()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you choosing to strip whitespace here? Is a bloom of 5000 space characters more valid than a bloom of 5000 letters?

Also what's the goal of the .get("content") call over a ["content"] lookup? This implies that the field is optional and has a reasonable default, but on line 158 you already asserted it was present.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the stripping question still stands here - why is a bloom that is one letter and then 5000 space characters more valid than a bloom that is 5001 non-space characters?

The user-facing limit doesn't feel like it was framed as "280 characters ignoring trailing spaces", it's framed as "280 characters". A space is a character.

I'm also still curious about the .get("content", "") vs ["content"]

Comment thread backend/endpoints.py Outdated
"error": "Content cannot be empty."
}), 400

if len(content) > 280:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is another place you'd need to update if you changed the limit.

Comment thread backend/endpoints.py Outdated
if len(content) > 280:
return jsonify({
"success": False,
"error": f"Content too long. Maximum 280 characters (current: {len(content)})."

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is yet another place you'd need to update if you changed the limit.

@illicitonion illicitonion removed the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Feb 17, 2026
@Luke-Manyamazi

Copy link
Copy Markdown
Author

Thank you Daniel, I have fixed the issues and now looks okay.

What I did:

  • Replaced hardcoded 280 limit with Bloom.MAX_CONTENT_LENGTH
  • Reject blooms that are empty or only whitespace

@Luke-Manyamazi Luke-Manyamazi added the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Feb 17, 2026
@illicitonion illicitonion removed the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Feb 25, 2026
@Luke-Manyamazi Luke-Manyamazi added the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Mar 7, 2026
@Luke-Manyamazi

Copy link
Copy Markdown
Author

"Hi Daniel, thanks for the feedback! I've refactored the validation to address your points:

DRY Constants: Moved the limit to Bloom.MAX_CONTENT_LENGTH in the model. All logic and error messages now reference this single constant.

Whitespace: Updated send_bloom to check the raw length first (so spaces count toward the limit) before calling .strip() for database cleanliness.

Attribute Access: Fixed the TypeError in the timeline by switching from dictionary keys to proper object attributes (.sent_timestamp).

Clean Lookups: Switched to direct ["content"] access since verify_request_fields already guarantees the field exists.

Ready for another look!"

@illicitonion

Copy link
Copy Markdown
Member

This PR now contains a lot of unrelated changes - please can you revert down to only adding the changes you need to fix this bug? I'm expecting the change to be about 5 lines of code in total.

@illicitonion illicitonion removed the Needs Review Trainee to add when requesting review. PRs without this label will not be reviewed. label Mar 11, 2026
@github-project-automation github-project-automation Bot moved this from Backlog to Done in Purple Forest Kanban Apr 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Module-Legacy-Code The name of the module. Reviewed Volunteer to add when completing a review with trainee action still to take. 📅 Sprint 1 Assigned during Sprint 1 of this module

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants