[jmrplens]

Refs #1165

This is the second layer of the first #1165 stack, the keyset oracle the plan's question 27 settled on and the rule that reads it. The live GitLab record (docs/development/gitlab-api-live.json, written by cmd/gen_api_live) now says, for every route, where the code it reaches calls one of GitLab's keyset paginators and which parameter its next page is asked by, and it is re-recorded on 19.5.0 at schema version 5. R-PAGE reads it: it holds every action's page_token to the routes the action sends, and every list GitLab can page by keyset to the next_page_token it is followed by. Nothing in the record could give that answer before, because GitLab reads pagination=keyset without declaring it: of the 53 routes whose code reaches a keyset paginator at v19.5.0-ee, four declare pagination and 22 declare no cursor either.

What the record says now

Each route whose code reaches a keyset paginator carries a keyset list, one entry per place its code calls one. An entry names the paginator, the file and line of the call with the line quoted, the helpers the walk went through to reach it (present_projects, render_work_items_collection_for), the parameters the next page is asked by, and the feature flags the call is behind with their defaults. A route without keyset reaches no keyset paginator, so GitLab answers it with an offset page whatever pagination says; in schema 4 the same absence meant "not recorded", which is why the version moved, the same inversion every earlier bump guarded against.

A site says where GitLab can serve a keyset page, not that it does. paginate_with_strategies picks CursorPager or Keyset::Pager by the model of the relation it is handed and answers 405 to a model and order it does not support, and the walk reads code, not the relation a request builds. So a paginate_with_strategies site carries CursorPager's cursor unless the call passes use_cursor: false, which assumes a model with keyset orderings. The two service account token lists page PersonalAccessToken, which declares none: the record gives them cursor, and GitLab answers every keyset request there with 405 and never reads it. The comments of the field, of apilive.KeysetSite and of the script say so, and R-PAGE declares those routes rather than trusting the site (below).

The five paginators the walk recognizes are paginate_with_strategies, GitalyKeysetPager, a finder executed with gitaly_pagination: true (the internal Orbit commit list), a route writing its own next link or cursor headers through Gitlab::Pagination::Keyset::HeaderBuilder (the instance audit events, the registry tags, the work item discussions), and keyset_paginate (the work item discussion notes and the MLflow searches).

The record also carries keyset_paginators, which parameter each of GitLab's library paginators names in its next link. I did not copy those names into the script: it has CursorPager, Keyset::Pager and GitalyKeysetPager each write a next link through the method GitLab calls after serving a page, and reads the parameter back (cursor, id_after and id_before, page_token, and cursor for the X-NEXT-CURSOR header). A release that renames one changes the record rather than leaving it wrong. The source block counts the keyset routes, and the gate holds the count to the content like the other figures.

How the walk works

introspect.rb takes each route's block from the endpoint Grape built, compiles the helpers it is served with the way Grape does when it mounts the endpoint (a runner never mounts one), and reads the instruction sequence of the block and of every helper of GitLab's own it calls on the endpoint, following super into the CE method an EE module overrides. It records a site at a call to one of the paginators above; the cursor of paginate_with_strategies is CursorPager's unless the call passes use_cursor: false, the cursor of a route's own next link is the key of the hash it hands the builder, and the cursor of keyset_paginate is the param it is handed. A feature flag is recorded on the sites it guards when it is tested as if Feature.enabled?(:flag) or unless Feature.disabled?(:flag), which reads unambiguously from the branch instructions; that is how the commit list comes out behind commits_keyset_pagination, shipped off. The walk takes about forty seconds inside the container.

The walk follows calls on the endpoint, never calls on a finder or a service, so a route a service pages by keyset on its own would read as paged by offset. That is what the new gate rule is for: a route declaring a parameter the record knows as a cursor is one that says it pages by keyset in its own words, and if it records no site, or no site asked by that parameter, the walk and GitLab disagree. All 31 routes that declare a cursor at 19.5.0 carry a site asked by it.

What the gate refuses

make check-api-live, and the generator before it writes, refuse a version 5 record without keyset_paginators (what a version 4 script labeled 5 produces), one below a floor of 35 keyset routes, a site naming a paginator nothing reads, a site with no file and line or no cursor, a probe naming no parameter or one nothing reads, and a route declaring a cursor the record does not follow. A passing run prints one more line, how many routes reach a keyset paginator and how many only behind a flag GitLab ships off.

The re-record

I booted gitlab/gitlab-ee:19.5.0-ee.0 alone on the remote Docker host, the digest the record already names (sha256:f04c71f565601283971d6472dd466609f4679450526f39aab3e3dcd6d23dc0ec), with go run ./cmd/gen_api_live/ -image gitlab/gitlab-ee:19.5.0-ee.0. Apart from the keyset half, the note, the schema version and the provenance, the record is what it was: entities, routes, features and both fine-grained halves compare equal under jq -S, and the source figures are unchanged.

The record marks 53 routes. Of the routes this server's actions send, it marks every one the first layer's classification found paging by keyset or refusing it (the 13 that follow it, the 5 refused by ordering, the 2 refused always and project.list_user_contributed). Each carries the cursor the classification found, last on the registry tags and id_after/id_before on the project lists included, except the two service account token lists, which the classification found refusing every keyset request and the record gives CursorPager's cursor, for the reason above. Two of the routes it marks are ones the classification called ignored, and every other route it marks is one no action of ours sends: the work item REST routes, the MLflow searches, the internal Orbit routes, GET /pipelines, the package pipelines and the admin data management list. Of the two, the commit list (repository.commit_list, repository.file_history) reaches GitalyKeysetPager behind commits_keyset_pagination, which the record says is off by default, so it agrees with the classification on a default instance. GET /groups reaches paginate_with_strategies only for an anonymous caller (present_groups_with_pagination_strategies returns early for a signed-in one); the record names the helper but not that condition, since an early return is not a shape the walk reads, and this server always signs in.

R-PAGE reads it

R-PAGE asked whether a list says where it ends, and a keyset route raised no finding by design, because the params could not say which routes GitLab pages by keyset. Its new keyset half (pagination.keyset in the report, cmd/audit_1to1/internal/paths/pagination_keyset.go) joins each action to the REST routes it sends through docs/development/action-requests.json, so it judges at the action's own grain, and reports four problems:

• page-token-on-offset-route: the action offers page_token and no route it sends can be paged by keyset, so GitLab ignores the parameter or refuses it.
• keyset-route-without-page-token: a read whose output is a list sends a route GitLab can page by keyset and does not offer page_token.
• keyset-route-without-next-page-token: the action offers page_token on a keyset route and its output carries no next_page_token.
• keyset-route-never-followed: the action offers page_token on a keyset route and no package serving it (its owner, or the package of a handler or site the request record names) was recorded sending the route one of the parameters its next page is asked by. This one is at the inventory's package grain, which the half's grain says.

A site behind a flag GitLab ships off counts as keyset: an instance that turns the flag on, GitLab.com for the commit list, pages the route by keyset, and the action's page_token is what reaches it there.

A route the record marks and GitLab serves this server no keyset page it can follow is declared in a new category, keyset-not-followable (declaredKeysetRoutes in pagination_declarations.go), each entry with what GitLab's handler does at v19.5.0-ee, by file and line:

• GET /groups: only an anonymous request reaches the keyset branch (lib/api/groups.rb:171).
• GET /groups/:id/service_accounts/:user_id/personal_access_tokens and GET /projects/:id/service_accounts/:user_id/personal_access_tokens: PersonalAccessToken has no keyset orderings, so every keyset request is answered 405 (lib/api/helpers/pagination_strategies.rb:30-43).
• GET /users/:user_id/contributed_projects: the finder is built without params, so the next link GitLab writes is never applied (upstream-bugs row 112).

A declared route is held to as offset: an action offering page_token on one is reported, with the route in its not_followable, and a list sending one without page_token is declared. A declaration no finding uses is stale and fails the gate, like every other declaration table of R-PATH; the findings themselves report and do not gate, as the collection half's do.

The route counts read the record's keyset field instead of the params: keyset_routes goes from the 10 routes that declare per_page without page to the 53 whose code reaches a keyset paginator, and a route can count as offset as well. Against the committed record, 202 actions offer page_token. 20 of them offer it on a keyset route, and every one publishes next_page_token and was followed in the unit suite. 182 offer it on an offset route, which is exactly the first layer's classification of ignored and keyset-not-followed actions without the commit list. The three lists that send a keyset route without page_token, group.search and the two token lists, are declared. Taking page_token out of those 182 inputs is the next stack of #1165.

Also in this layer

A second commit leaves cmd/gen_api_live with no mutant the mutation run cannot judge. runnerDetail cut the runner's stderr under a length test whose boundary is an equivalent mutant (at exactly the limit the cut and the whole are the same text), and the two boot defaults multiplied in package-level initializers, which no coverage profile records. The tail is now cut with max and the defaults are parsed from "20m" and "10s"; the values and the behavior are unchanged.

How I tested it

I wrote and measured this layer on the first layer as it stood over e3e09d290, and then rebased the stack twice: onto main at 6c9066aef, after the OpenSSF Best Practices stack, and onto main at 56758fb71, after the access level and edition tier stack (#1567 to #1571). The rebases changed nothing in this layer's lines. In the Go and Ruby files this layer touches, main changed only the copyright and SPDX header at their top; what it changed in the Makefile, docs/development/cmd-utilities.md and docs/development/request-paths.md lies outside the lines this layer edits there, and merged without a conflict. The six files this layer adds (keyset.go and its test in cmd/gen_api_live and in cmd/internal/apilive, pagination_keyset.go and its test in cmd/audit_1to1/internal/paths) now open with that header too, written by make fix-file-headers into the commit that adds each. What I ran again after the rebases is at the end of this section.

The three generator tests the plan asked for came first and were red on the stack's first layer, a35673d89 before the rebases, compiled against it unchanged: TestRunGenerate_ARouteCarryingAKeysetPaginator_ComesOutMarked (the route came out with keyset = <nil>, and so did the probe and the count), TestRunCheck_ARouteDeclaringACursorTheRecordDoesNotFollow_IsRefused and TestRunCheck_AVersion4RecordLabeled5_IsRefused (the parent refused both records only as schema version 5 and this build reads version 4). They edit the fixtures as JSON so they mean the same thing on a build with no keyset field, and they pass on this branch. Every rule has a case of its own in TestKeysetProblems_EachRule_NamesWhatItRefuses, with the whole sentence asserted, the floor at its edge and the shapes 19.5.0 records held to pass. The order of the generator's refusals has a case too: with the fine-grained and keyset refusals swapped, the second case of TestRunGenerate_AKeysetSiteNothingReads_IsRefusedAfterTheFineGrainedHalf fails.

The R-PAGE cases read the keyset half as JSON, the way a reader of the report does, and were red on the parent commit, 1ece15937 before the rebases (the pagination check carries no keyset half, and the route counts read off the params), compiled against it unchanged; the cases of the declaration table are new code and could not compile there. TestRun_TheRealTree_PassesItsOwnGate now also holds the summary's keyset figures to the findings they count.

cmd/audit_1to1/internal/paths, cmd/gen_api_live, cmd/internal/apilive and cmd/gen_action_grants/internal/join are at 100% statement coverage, gobco reads 1114/1114, 254/254, 186/186 and 304/304 conditions, and make coverage-mutants reads Killed 564, 216, 102 and 156, with Lived 0 and Timed out 0 on all four and Not covered 0 on the last three. cmd/audit_1to1/internal/paths also reports 483 mutants not covered, and every one is an ARITHMETIC_BASE on a + between string literals in a package-level initializer, on a line this layer does not change: the declaration tables of sent_declarations.go, shape_declarations.go, endpoint_declarations.go, orbit_declarations.go and pagination_declarations.go, a constant and a map of published.go, and a regular expression of endpoints.go. A - there does not compile, which is the tool artifact docs/development/testing/README.md describes; the new declaration table writes each reason as one literal for that reason, which took out the 14 it would have added. Before the rebase, make analyze passed every step but markdownlint, which could not start on the remote runner (npx: not found), and the same markdownlint command passed when run locally on the tree. make check-api-live, make check-action-grants-derivation, make check-action-grants, make audit-1to1-grants, make audit-1to1-paths, make check-e2e-static, make check-tenancy, make check-test-file-names and go run ./cmd/format_md_tables/ --check passed on the head, node scripts/check-doc-links.mjs passed, GITLAB_MCP_TEST_SNAPSHOT_PARITY=deferred go test ./... -count=1 passed on the head (294 packages), and the e2e packages compiled.

After the second rebase, on this head: GITLAB_MCP_TEST_SNAPSHOT_PARITY=deferred go test ./... -count=1 passes (301 packages), golangci-lint run --build-tags e2e and golangci-lint fmt --diff pass on the four packages, the e2e packages compile, and make check-api-live, make check-action-grants-derivation, make check-action-grants, make audit-1to1-grants, make audit-1to1-paths, make check-e2e-static, make check-tenancy, make check-test-file-names and make check-md-tables pass. R-PAGE's figures are the ones above: 53 keyset routes, 202 actions offering page_token, 20 of them on keyset routes, 182 on offset routes and 3 lists declared. make check-file-headers and make check-dco against the first layer pass. I did not measure coverage, conditions or mutants again, since the rebases changed no statement of the four packages, and the SonarCloud commit below changes only the Ruby script, which no Go coverage profile reads.

SonarCloud

SonarCloud reported three findings on cmd/gen_api_live/introspect.rb in this pull request, and a fourth commit answers them without changing what the script records:

• rubydre:S7815, a raise of a bare string in next_link_of: it now raises MissingNextLinkError, a StandardError of its own, with the same message.
• rubydre:S3776, KeysetWalk#scan at a cognitive complexity of 25 against 15: scan keeps the loop over a sequence and hands each instruction to scan_instruction, which reads it in four steps of their own (open_guard, read_operand, read_flag_call and follow_call), and what it carried in locals from one instruction to the next is a ScanState.
• rubydre:S107, record_site with ten parameters against seven: it takes the ScanState, the call, the index and the flags.

The script only runs inside a booted GitLab, so I held the new walk to the old one directly: a harness loads the keyset half of both versions under one Ruby and walks a fixture whose methods reach every paginator kind the walk recognizes, flag guards of both recorded shapes and the shapes it leaves unrecorded (an early return, if Feature.disabled? and unless Feature.enabled?), nested blocks, helpers, a call to super and a recursive helper. Over five entry points both versions record the same 35 sites in the same order, with the same via, cursors and flags, and the probe fails with the same message. go test ./cmd/gen_api_live/ ./cmd/internal/apilive/ and make check-api-live pass, and the record does not change, since it holds a digest of what the script answered and not of the script.

On that commit SonarCloud then reported rubydre:S131, the case in scan with no default branch. A fifth commit gives it one that reads nothing, with a comment saying why: an instruction list holds line numbers, labels and events, and instructions. The harness finds the same 35 sites and the same error, and the two checks above pass again.

What the top of this stack does

The contributor documentation of schema 5 and of R-PAGE's keyset half (the gen_api_live section and the R-PAGE paragraph of docs/development/cmd-utilities.md, the check-api-live row of docs/development/static-analysis.md, the R-PAGE paragraph of docs/development/request-paths.md and its line in CLAUDE.md) and docs/development/testing/testing.md are refreshed at the top of this stack, with the rest of its regeneration. This layer regenerates no committed artifact, so go run ./cmd/gen_testing_docs/ --check fails here on the new tests, as the FRESHNESS deferral below a stack's top expects.

#1517

Nothing here overlaps #1517, which changes neither the record, its generator nor R-PAGE, and no file of this layer is one #1517 changes. The merge request diffs route it pages is one the record marks as offset, as the review of #1517 expected, so R-PAGE reports mr_review.changes_get among the 182 actions offering page_token on an offset route; taking it out of that input is #1530, which waits for #1517. Whichever of #1517 and this stack lands second regenerates the artifacts both change.

[sourcery-ai]

Sorry @jmrplens, your pull request is larger than the review limit of 150,000 diff characters

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: jmrplens/gitlab-mcp-server
• Branch: issue-1165-keyset-oracle
• File: .coderabbit.yaml
• Commit: c22b625
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 378e087d-ba7f-46ab-952f-2d4a087378a1

Commits

Reviewing files that changed from the base of the PR and between 88a1b9e and c22b625.

Files selected for processing: 29

• Makefile
• cmd/audit_1to1/internal/paths/analyze.go
• cmd/audit_1to1/internal/paths/analyze_test.go
• cmd/audit_1to1/internal/paths/doc.go
• cmd/audit_1to1/internal/paths/pagination.go
• cmd/audit_1to1/internal/paths/pagination_declarations.go
• cmd/audit_1to1/internal/paths/pagination_declarations_test.go
• cmd/audit_1to1/internal/paths/pagination_keyset.go
• cmd/audit_1to1/internal/paths/pagination_keyset_test.go
• cmd/audit_1to1/internal/paths/pagination_test.go
• cmd/audit_1to1/internal/paths/shapes.go
• cmd/audit_1to1/internal/paths/shapes_test.go
• cmd/gen_action_grants/internal/join/doc.go
• cmd/gen_api_live/authorization.go
• cmd/gen_api_live/authorization_test.go
• cmd/gen_api_live/doc.go
• cmd/gen_api_live/introspect.rb
• cmd/gen_api_live/keyset.go
• cmd/gen_api_live/keyset_test.go
• cmd/gen_api_live/main.go
• cmd/gen_api_live/main_test.go
• cmd/internal/apilive/doc.go
• cmd/internal/apilive/keyset.go
• cmd/internal/apilive/keyset_test.go
• cmd/internal/apilive/live.go
• cmd/internal/apilive/live_test.go
• docs/development/cmd-utilities.md
• docs/development/gitlab-api-live.json
• docs/development/request-paths.md

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

📝 Summary

Summary by CodeRabbit

• New Features
  • API audits now identify keyset-pagination routes, check whether actions accept page tokens and publish next-page tokens, and flag routes that are not followed in recorded requests.
  • Audit reports include keyset-pagination counts and findings, with gaps-only reports retaining undeclared findings.
  • Live API records now capture keyset paginator and cursor details, with validation of the recorded data.
• Documentation
  • Updated guidance describes keyset-pagination coverage and the new live API record format.

The API-live record advances to schema 5 and records keyset paginator sites, cursor parameters, and route counts. The generator validates this data. The pagination audit uses it to classify routes and report action-level gaps in token offering and follow-up requests.

Changes: Keyset pagination record and audit

Layer / File(s)	Summary
Schema and keyset discovery cmd/internal/apilive/*, cmd/gen_api_live/introspect.rb, docs/development/gitlab-api-live.json, docs/development/request-paths.md, cmd/gen_action_grants/internal/join/doc.go	Schema 5 records paginator probes, route sites, cursor parameters, and keyset-route counts. The introspector scans route code and emits the data; the committed snapshot and schema references are updated.
Validate and generate the live record cmd/gen_api_live/*, Makefile	The generator validates paginator probes, route sites, cursor declarations, and the minimum keyset-route count. Reports include keyset counts, and generation refuses records with keyset validation problems.
Classify offset and keyset routes cmd/audit_1to1/internal/paths/pagination.go, cmd/audit_1to1/internal/paths/shapes.go, cmd/audit_1to1/internal/paths/pagination_test.go, cmd/audit_1to1/internal/paths/shapes_test.go, cmd/audit_1to1/internal/paths/doc.go	Offset pagination requires both page and per_page. Keyset pagination comes from recorded paginator sites, and a route can be classified as both.
Audit action tokens and follow-up requests cmd/audit_1to1/internal/paths/pagination_keyset.go, cmd/audit_1to1/internal/paths/pagination_declarations.go, cmd/audit_1to1/internal/paths/analyze.go, cmd/audit_1to1/internal/paths/*_test.go	The audit checks action token inputs, pagination outputs, and recorded cursor requests. It reports findings, tracks non-followable route declarations, and adds keyset summary counts and gaps-only filtering.

Priority: Normal

Estimated code review effort: 4 (Complex) | ~60 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant LiveRecord as API-live record
  participant Audit as R-PAGE audit
  participant RequestInventory
  participant Report
  Audit->>LiveRecord: Read route keyset sites and cursor parameters
  Audit->>RequestInventory: Read action and request data
  Audit->>Report: Record token, output, and cursor-use findings

Loading

Possibly related issues

• Re-pin the REST live record, the fine-grained table and the GraphQL schema on GitLab 19.6.0 when it ships #1492 — This change updates the live record to schema 5 with keyset data; the issue describes a subsequent live-record re-pin as a follow-up requirement.
• mr_review.changes_get accepts order_by, sort, pagination and page_token, which its route ignores #1530 — The new R-PAGE checks evaluate action pagination inputs against route pagination behavior, including the type of mismatch described in this issue.

Possibly related PRs

• jmrplens/gitlab-mcp-server#1517 — It adds pagination output metadata and request inventory rows that the R-PAGE audit evaluates.

Suggested reviewers: sourcery-ai

Merge Risk: Minimal · up to c22b6

No actionable issue is established for this change; it is mergeable after normal checks.

Pre-merge checks: 4 · 1

Failed checks: 1 inconclusive

Check name	Status	Explanation	Resolution
Description check		The description is thorough and closely follows the template's intent. It gives a detailed Changes section (schema 5 keyset record, the R-PAGE keyset half, the four problem kinds, and the new keyset-n…	Mark the change type (for this change, likely New feature and Enhancement, plus Documentation update and CI / build / tooling if they apply). Confirm the related issue line in the template format, for example 'Refs #1165' or 'Closes #'. Add…

Passed checks: 4 passed

Check name	Status	Explanation
Title check		The title clearly identifies the schema 5 keyset-route record and the R-PAGE page_token change. It is specific and aligned with the main changes.
Docstring Coverage		Docstring coverage is 93.02% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentati…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

Docstring coverage is 93.02% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 86 functions across 25 files. (4 skipped: 4 unsupported.)

Full details: Description check

Explanation

The description is thorough and closely follows the template's intent. It gives a detailed Changes section (schema 5 keyset record, the R-PAGE keyset half, the four problem kinds, and the new keyset-not-followable declarations), a detailed testing section with exact commands and results, and it names the related issue (Refs #1165). It also explains the rebases and the SonarCloud fixes. Gaps: the template's 'Closes #' line is replaced by 'Refs #1165' (acceptable, since the template allows Refs). The 'Type of Change' checkboxes are not marked, and the description does not state a type. The checklist is not addressed item by item. Nothing in the description says whether the Breaking Changes section applies, though the change does alter the schema version and route counts for consumers. The 'How to Test' section is written as prose rather than numbered steps, but it does list concrete commands.

Resolution

Mark the change type (for this change, likely New feature and Enhancement, plus Documentation update and CI / build / tooling if they apply). Confirm the related issue line in the template format, for example 'Refs #1165' or 'Closes #'. Add a Breaking Changes / Migration Notes entry, or write N/A with a reason. The schema bump from version 4 to version 5 and the changed meaning of the route keyset and pagination fields may affect consumers of the record. Put the How to Test steps in a numbered list that a reviewer can follow. Confirm the checklist items in the template (for example, DCO sign-off, file headers, and documentation updates), either by checking them or by noting which ones are deferred to the top of the stack.

Finishing Touches: 💡 1

🛠️ Fix failing CI checks: 💡

• Commit to this branch
• Create a new PR

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud