Skip to content

fix(remote): GitLab API data models to deserialize safely#1368

Open
ognis1205 wants to merge 2 commits intoorhun:mainfrom
ognis1205:fix/remote-gitlab
Open

fix(remote): GitLab API data models to deserialize safely#1368
ognis1205 wants to merge 2 commits intoorhun:mainfrom
ognis1205:fix/remote-gitlab

Conversation

@ognis1205
Copy link
Contributor

Description

The current implementation of the GitLab Remote API data models diverges from the official OpenAPI specification in terms of optional/required fields:

https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/openapi/openapi.yaml

As a result, JSON ser/de errors occur in practice. This change fixes those mismatches to ensure reliable ser/de behavior.

Closes #1366 #687

Motivation and Context

The current implementation of the GitLab Remote API data models diverges from the official OpenAPI specification in terms of optional and required fields. This mismatch caused JSON ser/de errors, which could lead to panics when fetching data from the GitLab remote API.

This PR first fixes the optionality mismatches in the data models, and as a result resolves the panic that occurred during GitLab remote fetches.

Additionally, similar JsonErrors should have also occurred in implementations prior to v2.10:

b82221a#diff-9d830e0be5fc20135aee3ba39934c06263208881475d426a20c85a3b7dbba385L242-L251

However, due to the use of take_while, these errors were unintentionally silenced, resulting in silent failures instead of visible errors. This fix therefore also addresses issues related to those previously hidden
JSON deserialization errors.

How Has This Been Tested?

  • cargo test

No additional tests were added, as this change only adjusts data model definitions and does not modify runtime logic.

Screenshots / Logs (if applicable)

N/A

Types of Changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation (no code change)
  • Refactor (refactoring production code)
  • Other

Checklist:

  • My code follows the code style of this project.
  • I have updated the documentation accordingly (if applicable).
  • I have formatted the code with rustfmt.
    • cargo +nightly fmt --all
  • I checked the lints with clippy.
    • cargo clippy --tests --verbose -- -D warnings
  • I have added tests to cover my changes.
  • All new and existing tests passed.
    • cargo test

Signed-off-by: Shingo OKAWA <shingo.okawa.g.h.c@gmail.com>
@ognis1205 ognis1205 requested a review from orhun as a code owner February 5, 2026 16:52
@ognis1205
Copy link
Contributor Author

One concern I have is that the way required/optional fields are modeled on the git-cliff side feels somewhat ad-hoc. While this PR should fix concrete ser/de issues, the overall data model design around optionality may not be entirely clean from a design perspective.

@codecov-commenter
Copy link

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 44.14%. Comparing base (91e65f5) to head (8e27ae7).

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1368   +/-   ##
=======================================
  Coverage   44.14%   44.14%           
=======================================
  Files          24       24           
  Lines        2286     2286           
=======================================
  Hits         1009     1009           
  Misses       1277     1277           
Flag Coverage Δ
unit-tests 44.14% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@ognis1205
Copy link
Contributor Author

#[serde(default)] would be a bit cleaner.

@orhun
Copy link
Owner

orhun commented Feb 6, 2026

Yeah, we could use #[serde(default)] I agree

Comment on lines +1 to +2
TEST

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
TEST

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Panic when description is null in GitLab Merge Request JSON

3 participants