[ENGG-5120]: Add optional rank field to API data structure

[dinex-dev]

Summary by CodeRabbit

• New Features
  • Added support for an optional rank field in API records and responses.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[linear]

ENGG-5120 Local sync changes

[coderabbitai]

Walkthrough

This pull request introduces a new optional rank field across the API layer. The rank property is added to type definitions in types.ts and schemas.ts, and the utility function in fs-utils.ts is updated to map the rank value from parsed records into the API data payload when constructing API objects.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and accurately describes the main change: adding an optional rank field to the API data structure across multiple files.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 56d9654 and 7f0e312.

📒 Files selected for processing (3)

• src/renderer/actions/local-sync/fs-utils.ts
• src/renderer/actions/local-sync/schemas.ts
• src/renderer/actions/local-sync/types.ts

🔇 Additional comments (3)

src/renderer/actions/local-sync/schemas.ts (1)

128-138: Clarify intent: rank is defined in both BaseRequest and ApiRecord.

The rank field is added to both BaseRequest (line 130) and ApiRecord (line 178). Since ApiRecord.request is of type ApiRequest (which inherits from BaseRequest), this creates two potential locations for rank:

• ApiRecord.rank
• ApiRecord.request.rank (via BaseRequest)

In fs-utils.ts, only record.rank (the ApiRecord level) is mapped to api.data.rank. Is the rank in BaseRequest intentionally separate, or should it be removed to avoid confusion?

Also applies to: 176-180

src/renderer/actions/local-sync/fs-utils.ts (1)

986-991: LGTM!

The rank field is correctly mapped from the parsed record to the API data payload. The optional nature of the field is preserved, aligning with the schema and type definitions.

src/renderer/actions/local-sync/types.ts (1)

83-88: LGTM!

The rank?: string field is correctly added to the API.data type, maintaining consistency with the schema definition in schemas.ts and the mapping logic in fs-utils.ts.

---

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 and usage tips.}