chore: await params in v1 endpoints

[adityachoudhari26]

Summary by CodeRabbit

• Refactor
  • Improved the handling of route parameters across multiple API endpoints to ensure consistent and asynchronous resolution before use.
  • Simplified authorization checks and parameter extraction for better reliability and maintainability.
• Bug Fixes
  • Enhanced safety when accessing route parameters by adding default fallbacks, reducing the risk of undefined values during authorization and data operations.

[coderabbitai]

Walkthrough

This set of changes updates several API route handlers to handle route parameters asynchronously by changing the params argument from a synchronous object to a Promise that resolves to the parameter object. Handler functions now explicitly await the params promise before destructuring route parameters. Authorization middleware and handler signatures are updated accordingly to reflect this asynchronous pattern. Additionally, parameter access within authorization checks is streamlined, and fallback values are added where necessary. The core business logic and error handling remain unchanged.

Changes

File(s)	Change Summary
apps/webservice/src/app/api/v1/cloud-locations/[provider]/route.ts	Changed GET handler to async, updated params to a Promise, and adjusted parameter extraction accordingly.
apps/webservice/src/app/api/v1/deployment-versions/[deploymentVersionId]/route.ts	Updated authorization and handler signatures to use async params, ensured string fallback for ID, adjusted access.
apps/webservice/src/app/api/v1/deployments/[deploymentId]/deployment-version-channels/name/[name]/route.ts	Simplified authorization, changed handler to use async params, updated parameter extraction and usage.
apps/webservice/src/app/api/v1/deployments/[deploymentId]/release-channels/name/[name]/route.ts	Simplified authorization, updated handler to use async params, and adjusted parameter extraction and usage.
apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts	Updated GET, DELETE, PATCH handlers to use async params, unified parameter access, and simplified authorization.
apps/webservice/src/app/api/v1/environments/[environmentId]/route.ts	Updated GET, DELETE handlers to use async params, simplified parameter extraction, and streamlined authorization.

Possibly related PRs

• fix: Release channel delete endpoint #224: Introduced the DELETE handler for release channel deletion, which is directly modified in this PR to handle asynchronous params and simplify authorization.

Suggested reviewers

• jsbroks

Poem

In the warren of code, where the routes run deep,
Async params now hop, no longer leap.
Awaiting their turn, each ID in tow,
The handlers all cheer, "Now ready to go!"
With paws on the keyboard and whiskers a-twitch,
This rabbit declares: "Async is rich!"
🐇✨

---

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 46a8967 and eaab02d.

📒 Files selected for processing (6)

• apps/webservice/src/app/api/v1/cloud-locations/[provider]/route.ts (1 hunks)
• apps/webservice/src/app/api/v1/deployment-versions/[deploymentVersionId]/route.ts (1 hunks)
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/deployment-version-channels/name/[name]/route.ts (1 hunks)
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/release-channels/name/[name]/route.ts (1 hunks)
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts (4 hunks)
• apps/webservice/src/app/api/v1/environments/[environmentId]/route.ts (3 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

`**/*.{ts,tsx}`: **Note on Error Handling:** Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error...

**/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.

• apps/webservice/src/app/api/v1/cloud-locations/[provider]/route.ts
• apps/webservice/src/app/api/v1/deployment-versions/[deploymentVersionId]/route.ts
• apps/webservice/src/app/api/v1/environments/[environmentId]/route.ts
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/release-channels/name/[name]/route.ts
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/deployment-version-channels/name/[name]/route.ts
• apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts

🧠 Learnings (1)

apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts (1)

Learnt from: zacharyblasczyk
PR: ctrlplanedev/ctrlplane#382
File: apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts:82-88
Timestamp: 2025-03-16T19:41:44.129Z
Learning: In Next.js 15, dynamic route parameters (params) return Promises instead of direct values in async contexts. When accessing properties like `params.deploymentId` in an async function, use `(await params).deploymentId` to avoid the "params should be awaited before using its properties" error. This applies to API routes, page components, and other async contexts.

🧬 Code Graph Analysis (1)

apps/webservice/src/app/api/v1/cloud-locations/[provider]/route.ts (2)

apps/webservice/src/app/api/v1/environments/[environmentId]/route.ts (1)

• GET (10-37)

apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts (1)

• GET (13-39)

⏰ Context from checks skipped due to timeout of 90000ms (3)

• GitHub Check: build (linux/amd64)
• GitHub Check: Lint
• GitHub Check: Typecheck

🔇 Additional comments (23)

apps/webservice/src/app/api/v1/cloud-locations/[provider]/route.ts (1)

5-9: LGTM: Successfully updated to use async route parameters

The changes correctly implement the async pattern for route parameters:

1. Added async to the function signature
2. Updated param type to Promise<{ provider: string }>
3. Added await before accessing the provider parameter

This update follows the standard pattern being applied across all API routes in this PR.

apps/webservice/src/app/api/v1/deployments/[deploymentId]/release-channels/name/[name]/route.ts (3)

13-17: LGTM: Streamlined authorization middleware

The authorization middleware has been properly simplified to directly access params with a null coalescing fallback for the deployment ID. This matches the pattern used across other route handlers.

---

19-21: LGTM: Updated params handling to async pattern

The handler signature and implementation correctly:

1. Changed params type to Promise<{ deploymentId: string; name: string }>
2. Added proper awaiting of params before destructuring

---

27-29: LGTM: Updated query to use awaited parameters

The database query now correctly uses the awaited parameter variables instead of directly accessing params. This maintains consistency with the new async pattern.

apps/webservice/src/app/api/v1/environments/[environmentId]/route.ts (5)

13-17: LGTM: Streamlined GET authorization middleware

The authorization check has been properly simplified to directly access params with a null coalescing fallback for the environment ID.

---

19-24: LGTM: Updated GET handler to use async params

The GET handler correctly:

1. Updated the params type to Promise<{ environmentId: string }>
2. Added proper awaiting of params before destructuring
3. Updated database query to use the awaited variable

---

42-46: LGTM: Streamlined DELETE authorization middleware

Similar to the GET handler, the DELETE authorization check has been properly simplified to directly access params with a null coalescing fallback for the environment ID.

---

48-53: LGTM: Updated DELETE handler to use async params

The DELETE handler correctly:

1. Updated the params type to Promise<{ environmentId: string }>
2. Added proper awaiting of params before destructuring
3. Updated database query to use the awaited variable

---

62-62: LGTM: Updated DELETE operation to use awaited parameter

The environment deletion operation now correctly uses the awaited environmentId variable.

apps/webservice/src/app/api/v1/deployment-versions/[deploymentVersionId]/route.ts (2)

30-35: LGTM: Improved authorization middleware

The authorization middleware has been properly updated to:

1. Directly access params without nested destructuring
2. Use a more explicit object structure with type and id
3. Add a null coalescing fallback for the deployment version ID

---

39-41: LGTM: Updated handler to use async params

The PATCH handler correctly:

1. Updated the params type to Promise<{ deploymentVersionId: string }>
2. Added proper awaiting of params before destructuring

This matches the consistent pattern applied across all route handlers in this PR.

apps/webservice/src/app/api/v1/deployments/[deploymentId]/deployment-version-channels/name/[name]/route.ts (4)

13-16: Good improvement of parameter handling in authorization check

The authorization middleware has been simplified to directly access params instead of the previous nested structure. The addition of the nullish coalescing operator (??) provides a safe fallback empty string when deploymentId is undefined, which is a good defensive programming practice.

---

19-19: Properly updated handler parameter type to support async params

The type has been correctly updated to expect params as a Promise, which aligns with Next.js 15's behavior where dynamic route parameters are returned as Promises in async contexts.

---

21-21: Correctly awaiting params before destructuring

Good implementation of awaiting the params Promise before attempting to destructure and use its properties. This ensures the route parameters are properly resolved before being used in the database query.

---

27-28: Properly using awaited parameter values

The database query has been updated to use the awaited deploymentId and name variables instead of directly accessing them from params. This change ensures the query executes with the resolved parameter values.

apps/webservice/src/app/api/v1/deployments/[deploymentId]/route.ts (8)

16-19: Good simplification of authorization parameter access

The authorization middleware has been updated to directly access the params object, with a safe fallback using the nullish coalescing operator (??) when deploymentId might be undefined. This improves code robustness.

---

22-24: Correctly updated GET handler for async params

The handler's type signature has been properly updated to expect params as a Promise, and the code now correctly awaits the params before destructuring and using deploymentId. This aligns with Next.js 15's handling of dynamic route parameters.

---

28-28: Using awaited parameter in database query

The database query has been updated to use the awaited deploymentId variable, ensuring that the query uses the resolved parameter value.

---

44-47: Good simplification of DELETE handler authorization

Similar to the GET handler, the authorization middleware has been updated to directly access the params object with a safe fallback. This creates a consistent pattern across all handlers.

---

50-53: Correctly updated DELETE handler for async params

The DELETE handler's type signature has been properly updated, and the code now correctly awaits the params before destructuring and using deploymentId.

---

57-57: Using awaited parameter in DELETE queries

Both database operations in the DELETE handler now correctly use the awaited deploymentId variable instead of accessing it directly from params.

Also applies to: 68-68

---

84-88: Good simplification of PATCH handler authorization

The PATCH handler's authorization check has been updated to directly access the params with a safe fallback, maintaining consistency with the other handlers in this file.

---

90-90: Correctly updated PATCH handler type for async params

The PATCH handler's type signature has been properly updated to expect params as a Promise, consistent with the changes to the other handlers.

✨ Finishing Touches

• 📝 Generate Docstrings

---

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

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.