I’m not on the DEV team. I don’t have an admin panel, production database access, or internal Slack. Everything I know about how DEV works comes fr...
For further actions, you may consider blocking this person and/or reporting abuse
🐛 Plot twist: the bug wasn't the only thing I had to debug. My own test was wrong, too.
This started with four merged PRs and a missing badge. It turned into a dive through Forem's public code, a fix that got merged, and a code review that taught me why a passing test isn't always proof that your fix works.
Huge thanks to everyone who reviewed the PR and helped me catch what I'd missed!
Your turn: Have you ever had a test pass green while completely missing the bug it was supposed to catch? I'd love to hear that story. 👀
And Sir @francistrdev, I'd love a comment in here because I know you've contributed to forem before and skilled in ruby on rails.
Don't want to bother you, only when you're free!😅
Thank you for this!
This bug has been around so long it had completely faded from everyone's consciounseness.
Thank you so much, Sir! That really means a lot. It was such an awesome rabbit hole to trace from the outside.
Also, your reply really made my day!
Always happy to support the DEV Community!
Have A Great Day!
What type of PR is this? (check all applicable)
Description
Extends the existing
ProfilePinmodel (previouslyUser-only) to also supportOrganizationas aprofile_type, reusing the polymorphic pin/unpin pattern already used on individual user profiles.ProfilePinnow validatesOrganizationas a validprofile_typeand checks that a pinned article belongs to the organization (viaorganization_id) when the profile is an Organization.OrganizationProfilePinsController(slug-scoped, reusesOrganizationAdminScopedfor authorization) handles create/destroy of organization pins. Only org admins (or site admins) can pin/unpin.stories_controller#handle_organization_indexnow loads the organization's pinned articles separately from the regular chronological feed and excludes them from it, mirroringassign_user_storiesfor users.organizations/_main_feedrenders a dedicated "Pinned" section above the regular feed when pinned posts exist, reusing the same badge/styling as the user profile pinned section.published_at.Related Tickets & Documents
QA Instructions, Screenshots, Recordings
/dashboard, open "Manage" on a post that belongs to your organization./<org-slug>) — the post now appears in a "Pinned" card above the regular feed, and does not also appear in the regular feed below.POST /:slug/profile_pins(raisesPundit::NotAuthorizedError).UI accessibility checklist
_main_feed/single_storymarkup and existing pin badge markup)<button type="submit">form controls)CriticalandSeriousissues?Added/updated tests?
spec/models/profile_pin_spec.rb: organization pin validity, ownership check, 5-pin cap.spec/requests/organization_profile_pins_spec.rb: create/destroy as org admin, five-pin cap, rejecting pins for articles outside the org, authorization failures for member/outsider/signed-out user.spec/requests/stories_index_spec.rb: organization page renders the pinned section and does not duplicate the pinned post in the regular feed.[optional] Are there any post deployment tasks we need to perform?
None.
Thats so awesome! Good job!
Thanks! Have A Great Day!
Great work! Nice contribution 👍
Thanks!😄
Have A Great Day!
Same class, from the other side. I published a fix for a 422 "Invalid authenticity token" on a scripted comment POST, then tested it by posting a comment. Green. Posted a second one to be sure. Green.
Then I ran the same recipe cold, fresh cookie jar, and it 422'd. The token I'd been grabbing off the article page belonged to a different form. It only ever worked because of state left over in a warm session.
The test wasn't wrong about the fix. It was wrong about the world. Same shape as your factory default: the thing that made it green was a default I didn't know I'd chosen.
Borrowed from your takeaway: for anything auth-shaped, "it passed" usually means "it passed with the session I happened to be holding." The regression run has to start from nobody. That's the
git stashstep, just for cookies.(Token-side writeup, if the details are useful: dev.to/kaj_ilands/your-scripted-po...)
The Lesson B section is the one I will keep. A test that passes on main without the fix is not a regression test at all — it is just agreeing with the current behaviour, and the factory default hiding that is exactly the kind of quiet escape route that is easy to miss. The git stash check is cheap insurance, and your point about warn versus info lands too: a warning that fires on expected configuration just trains everyone to ignore warnings.
There's something pretty funny about earning your fifth merged PR by fixing the badge for your fourth 😄 The factory default was a sneaky one: the count was right, but the service was still attempting the duplicate. Nice example of why checking the final state alone can miss what went wrong.
Sure is, for whole morning I was like where's the badge?😅
And then I went like let me give my PR #5 a legendary arc.😄
But it was a really nice day!
Have A Great Day!
The allow_multiple_awards change is the part I'd turn into a reusable test habit: name the other mechanism that could make the assertion pass, then choose a fixture that removes that escape route. In this buggy movie-search exercise, I'd include both a published and an unpublished movie matching the same search. A broken matcher that returns nothing must not accidentally pass the filter test.
Spot on—explicitly closing the 'escape route' in the test fixture so the assertion can only pass through the exact code path you're testing is the real game-changer!
Lesson B deserves its systematic form: mutation testing is "run the spec against main" automated. Every surviving mutant is precisely a test that agrees with you - green for a reason other than the one you wrote it for. The cheaper habit that catches most of them is asserting on the mechanism, not only the outcome: your second-run test counted achievements, which the uniqueness validator also satisfies; counting create attempts would have separated first_or_create from silent validation failure.
Lesson A is the same rule as filtering a noisy error tracker: a warning that fires on expected configuration teaches operators to ignore the channel, and the cost is paid when a real one arrives. "warn means someone should act" has a corollary - on this install, with this config; expected absences are info by definition. And the OpenHands read-only lookup deserves a nod: confirming a falsifiable hypothesis against production data without mutating anything is the right instinct everywhere, not just in reviews.
Nicely done 👏
Thanks!😄
Have A Great Day!
Nice! 👏🏻
Bro, this is great! keep up the good work.
Thanks Bro!
I'm still learning ruby on rails. That's why my initial PRs were docs/front-end related and I made it to 4 merged PRs but didn't get the badge so today was the BUG SMASH DAY!😂
Your git stash check is the habit I now wish I had adopted earlier: I once celebrated a green test that was really just the validator refusing a duplicate, so my fix was never exercised at all. Your log-level point lands the same way for me, because a warn that fires every hour stops being a signal and becomes background noise. Do you now run the fail-on-main check for every regression test, or only for the ones that touch uniqueness?
Honestly, for every single regression test now! Taking 10 seconds to run
git stash, watch the spec fail on main, and rungit stash popis the cheapest insurance policy against false positives—especially when factories have hidden defaults.I would keep the stash check, but I would not trust it blindly for a new test, because git stash leaves untracked files behind by default. I once watched a spec pass on main for exactly that reason: the new factory file was still on disk, so the failure I expected never happened. Do you run the check with -u so new files are stashed too, or do you keep new files out of the regression check?