Be Careful with Gids in Rails
Key topics
The pitfalls of using Global IDs (GIDs) in Rails are sparking a lively debate, with some commenters pointing out that the real issue lies not with GIDs themselves, but with the misuse of Large Language Models (LLMs) to generate code. Notable Rails apps like Shopify and Delayed Job are already leveraging GIDs, and some users argue that the problem is not with GIDs, but with how they're being used - specifically, being generated without proper authorization checks. As one commenter astutely notes, GIDs are a powerful feature that can be used effectively with proper precautions, like generating signed GIDs using `to_sgid`. The discussion highlights the importance of understanding the limitations and potential misuses of both GIDs and LLMs.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
5d
Peak period
20
Day 6
Avg / period
10.5
Based on 21 loaded comments
Key moments
- 01Story posted
Dec 10, 2025 at 9:03 PM EST
23 days ago
Step 01 - 02First comment
Dec 16, 2025 at 8:01 AM EST
5d after posting
Step 02 - 03Peak activity
20 comments in Day 6
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 23, 2025 at 6:02 PM EST
10 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
That an LLM tripped it isn't really important. It could have been your user or your own botched id gen in a script.
Then the problem with this post boils down to applying the authorization layer in any tool call, just like you do in controllers. Seems obvious?
Obviously, this means that first gid was bogus anyway, as it was trying to look up via the wrong key, but the fact that it doesn't fail, and will instead return the record with primary key "22" can certainly be surprising.
If there’s a gotcha it’s that _signed_ global ids are only signed, not encrypted, and very few people seem to know about the optimised method (globalid::Locator.locate_many) for loading a batch of global ids
GID's are great - i think the issue is with how they leveraged rubyLLM for something they should inherently not be using LLMs for.
> Remember that GIDs were made for facilitating ActiveJob serialization - they are a system-level facility, not a product-level facility.
I think this is somewhat obvious given the signature like gid://awesome-app/Post/32; there is no scoping to the user or account so it should be treated like a global lookup. If you need scoping to a user/account you can build that.
Honestly I think this is a matter of the author using poor design decisions and over leveraging LLMs. But this is not the fault of Rails, it is working as expected.
Be careful with LLMs!
It's like writing an article about "the dangers of PostgreSQL" ... when generating SQL from an LLM. It has nothing to do with Postgres specifically, it's that you're generating queries to run in a trusted context from an untrustable origin.