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
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.
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.
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!
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?
