• Encountered more edge cases while running snapshot testing. I'll need to refactor how we build the router to sync the routing logic between the actual router and the test router we use solely for snapshot testing. The original approach I had in mind is flawed.
• Came up with a mapping of segment to example values after analyzing the segments that gives a realistic testing values. It's not realistic to come up with a perfect solution for this so I'll create future work items after this issue.

@daveyleach Yeah I use opencode a lot to come up with the first iterations, but most of the work is in weighing the trade-offs on design decisions and refining the requirements over iteration. I think this is a great case study for that. I'm happy to discuss this further on our 1-1 😃

I'm still actively working on this, but I didn't have enough time to push something by EOD.

What I'm working on:

• I've come up with a simple solution for snapshot testing where we just reuse the buildRouter method (now extracted as a function) and update pathBasedRoutes to be all assigned to a custom testHandler.
• I've been working on a script that goes through each template rails route and generate an example url. For example, :id can be a simple integer or a complicated regex with lookahead assertions depending on the template rails route. Ultimately, the MVC is to have an exhaustive list of URLs with a comment explaining how we manually obtained them. Next step, would be to automate the whole thing.
• I'll have to do something similar for api routes (Ruby Grape).

cc @daveyleach @samihiltunen

Sangwoo Han (527a3bf9) at 18 Mar 19:01

We ended up merging this mvc MR instead. We'll implement the additional changes from this MR incrementally instead.

What does this MR do and why?

Part of gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#626

Clean version of this reference MR: !457

This MR is too big, so we'll split it into a train of MRs:

MR 1: Test infrastructure — per-test database creation

• internal/stores/claim/database/helpers/test/test_helpers.go
• Replaces table truncation with per-test ephemeral databases
• 0 dependencies, can land first

MR 2: Move Bucket to shared types.v1 package

• New proto/types/v1/bucket.proto
• Update proto/claims/v1/messages.proto and service.proto to import from types.v1
• Update internal/stores/claim/store.go type alias to types_proto.Bucket_Type
• All cascading type reference updates in tests (types_proto.Bucket_* instead of claims_proto.Bucket_*)
• Regenerated Go/Ruby client code
• Purely a proto move — no Go logic changes beyond import swaps

MR 3: Extract helpers from internal/services/claim to internal/helpers/claim

• Move proto.go to internal/helpers/claim/proto.go, export all functions
• Move rules/normalization.go and rules/validation.go to internal/helpers/claim/rules/, with their tests
• New shared test helper internal/helpers/test/metadata.go
• Update all claim service files (begin_update.go, get_record.go, list_leases.go, commit_update.go, rollback_update.go) to call claim_helpers.X() instead of package-private functions
• Update claim service tests accordingly

MR 4: Feature — ClassifyByBucket endpoint

• Store layer: New GetCreatorID method on ClaimStore interface + pgx/spanner implementations
• Classify service: New ClassifyByBucket RPC implementation + tests
• Proto: Add ClassifyByBucketRequest and RPC to classify_service.proto
• Wiring: Update controller, add REST docs
• Generated client code for classify proto changes
• This is the actual feature MR, cleanly scoped

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

What does this MR do and why?

Draft MR to be only used as reference to keep track of commit history.

See the real MR here: !478

Why is this change being made?

💡 Provide a detailed answer to the question on why this change is being proposed, in accordance with our value of Transparency.

Please add the details saying why, not just what in this section. Example: We have discussed the topic in Slack - (copy of Slack conversation). The current process is not efficient, this MR makes the description of X more clear, and helps move Y forward.

CHANGEME

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
  • The when to get approval handbook section explains the workflow in more detail
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

Commits

---

What does this MR do and why?

Add comment linting rule to buf.yaml and document protobuf schemas

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#532

How to set up and validate locally

Run buf lint

MR acceptance checklist

• Documentation on protobuf schemas are thorough.
• buf lint returns no error.

What does this MR do and why?

Part of gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#626

This MR runs REF="swh/classify-with-claims" ./scripts/update-topology-service-gem.sh and makes the necessary derivative updates.

References

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

What does this MR do and why?

This MR is a portion of this big MR

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Why is this change being made?

This MR is part of gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#583

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---

What does this MR do and why?

How to set up and validate locally

What does this MR do and why?

How to set up and validate locally

Sangwoo Han (763982e7) at 17 Mar 19:57

What does this MR do and why?

Closes gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#620

How to set up and validate locally

Sangwoo Han (763982e7) at 17 Mar 14:43

nvm just saw your comment: !488 (comment 3155104716)