Reviewing Foundational Flows MR & Learning Rails Internals

TL;DR

• Thursday Aug 13, milestone crunch time with everyone rushing reviews and workouts
• Working an MR removing group-level disable functionality for foundational flows so they match agents
• Implemented via front-end branching logic and removing the back-end mutation to block API access
• Verifying Agent 4029’s and Agent 1486’s comments by digging into Rails constant path syntax, auto-loading, and verification level attribute
• Learned Ruby idioms: no for-loops in practice, .each is a method on all collection types, block params can be 1-3, and type can be inferred from usage (e.g., .each do |level, _| implies a hash with symbol keys)

MR Status and Task

It’s been a busy few days because the milestone is ending, and there’s crunch time with everyone trying to get things reviewed while also getting their own workouts and reviews done. Today, Thursday August 13th, I finished all my reviews for the week, so I’m working through an MR that no one has requested reviews from me on. We’re removing the group-level disable functionality for foundational flows so that they match how agents currently exist. I did this through basic branching logic in the front end and by removing the back-end mutation so it can’t be accessed at the API level.

Verifying Comments via Rails Navigation

I’m working on verifying some of Agent 4029’s comments as well as Agent 1486’s. I started by figuring out how to navigate Ruby on Rails, tracking down the verification level attribute, and with a basic search found where it’s used and defined as a type. Ruby has a constant path syntax where each module is represented by a folder/file hierarchy, separated by a double colon - so something like namespaces::verified_namespace::verification_level means a folder called namespaces, another folder called verified_namespace, and a class called verification_level with a function or attribute inside. A leading double colon means start from the root, which in Rails is the app folder. What’s challenging in a codebase as large as GitLab’s is pinning down the root issue - that’s roughly where I am right now.

Learning Ruby Type Inference and Iteration

Reading usage for type clues is interesting - calling .upcase on a variable obviously means it’s a string, but .each doesn’t tell you whether it’s a string, array, or other iterable, so you have to infer from context. A .each do |level, _| with two block parameters tells you it’s a hash (key-value pairs) before you ever see the definition. The fact that level.upcase works tells you the keys are symbols. The discarded second parameter suggests the values (integers) only matter to the database, not to the graph - though I don’t fully understand that part yet and suspect I need to dig deeper. I also learned that Ruby does have for-loops, but they’re almost never used - instead .each is called, which is a method defined on every collection type (hashes, arrays, enums). You can have one to three block parameters.