Merge pull request #938 from mayurigade-hub/fix/button-type-attributes

fix(forms): add explicit button types to form controls

Author: durdana3105

TROUBLESHOOTING.md

@@ -67,51 +67,36 @@ Welcome to the troubleshooting guide for Peer Learning! If you encounter problem
 - Verify that your Supabase instance has the correct authentication providers enabled.
 - If testing locally, ensure the Site URL in Supabase Auth settings is set to `http://localhost:5173` (or whatever port you are using).
 - For OAuth, verify that the Client ID and Secret match the ones configured in your OAuth provider's developer console, and that the callback URL matches your Supabase project's redirect URL.
-- After updating environment variables, restart the development server before testing authentication again.
-- If you encounter a "Failed to fetch" error during signup, verify that your `.env` file contains valid Supabase credentials and that the application has been restarted after any configuration changes.
 
-## 6. Push Notifications Not Delivering
+## 6. Push Notification Issues
 
-### Symptom: Cron runs but `sent` is always 0
+**Symptom**: Browser push notifications are not being received, or the notification bell shows no alerts despite new activity.
 
-**Check VAPID configuration.** The response body will contain `{ "error": "Missing VAPID push server env" }` if `VAPID_PUBLIC_KEY` or `VAPID_PRIVATE_KEY` are not set in `backend/.env`. Generate keys and set them:
-
-```bash
-npx web-push generate-vapid-keys
-```
-
-Add to `backend/.env`:
-```env
-VAPID_PUBLIC_KEY=<generated>
-VAPID_PRIVATE_KEY=<generated>
-VAPID_SUBJECT=mailto:admin@yourdomain.com
-```
-
-> Changing these keys invalidates all existing browser subscriptions. Users must re-subscribe.
-
-### Symptom: Cron returns `HTTP 401` or `403`
-
-`CRON_SECRET` is missing or does not match what the scheduler is sending. Verify the env var is set on the server and that the scheduler is passing `Authorization: Bearer <CRON_SECRET>`. Check `[AUDIT]` lines in server logs to confirm the secret type being presented.
-
-### Symptom: Cron returns `HTTP 429` immediately
-
-The 60-second per-route cooldown is active. The cron fired twice within 60 seconds (Vercel's at-least-once guarantee can cause this). Wait 60 seconds and retry. If this blocks manual drain, see the Manual Drain Procedure in `docs/smart-notifications.md`.
-
-### Symptom: Notifications accumulate but are never delivered (queue keeps growing)
+**Solution**:
 
-1. Confirm the cron scheduler is running and reaching the server (look for `[AUDIT]` log lines).
-2. Check queue depth:
-   ```sql
-   SELECT COUNT(*) FROM notifications WHERE push_sent_at IS NULL;
-   ```
-3. If the queue is large, manually drain it — see `docs/smart-notifications.md` → **Manual drain procedure**.
+### Browser Permission
+- Ensure the user has granted the browser notification permission. Open browser settings and verify that the site is allowed to show notifications.
+- If permission was denied, the user must manually re-enable it in the browser settings — the app cannot re-prompt automatically after a denial.
 
-### Symptom: `sent` is much lower than `processed` on every run
+### VAPID Configuration
+- Push notifications require valid VAPID (Voluntary Application Server Identification) keys. If you see `Missing VAPID push server env` errors in the backend logs, the following environment variables are not set:
+  ```env
+  VAPID_PUBLIC_KEY=
+  VAPID_PRIVATE_KEY=
+  VAPID_SUBJECT=mailto:your@email.com
+  ```
+- Generate a VAPID key pair using the `web-push` CLI:
+  ```bash
+  npx web-push generate-vapid-keys
+  ```
+- Set the same `VAPID_PUBLIC_KEY` in both the backend `.env` and the frontend (`VITE_VAPID_PUBLIC_KEY`). The keys **must** match — using different keys for frontend and backend will cause push subscriptions to be invalid.
 
-Most subscriptions in `push_subscriptions` are likely expired (browser was uninstalled, permission was revoked, or VAPID keys changed). The cron absorbs individual push failures silently. Check:
+### Subscription Expiry
+- Expired push subscriptions return `410 Gone` or `404 Not Found` from the push service. These subscriptions should be removed from the `push_subscriptions` table. If you observe a flood of 410/404 errors, run:
+  ```sql
+  DELETE FROM push_subscriptions WHERE updated_at < now() - interval '30 days';
+  ```
 
-```sql
-SELECT COUNT(*) FROM push_subscriptions;
-```
+### Cron Job Not Running
+- If push notifications were working and suddenly stopped, check that the `dispatch-push-notifications` Supabase Edge Function cron is still active. Navigate to **Supabase → Functions → dispatch-push-notifications → Logs** to verify it is firing every minute.
 
-If zero or very low, users need to re-subscribe by visiting the site and granting notification permission again.

backend/controllers/cronController.js

@@ -56,24 +56,14 @@ export const dispatchPushNotifications = async (req, res, next) => {
     webpush.setVapidDetails(vapidSubject, vapidPublicKey, vapidPrivateKey);
     const supabase = getSupabaseClient();
 
-    // --- Atomic claim --------------------------------------------------
-    // A single UPDATE … RETURNING claims the batch before any push is
-    // dispatched. Postgres guarantees that only one concurrent caller
-    // wins each row; the other sees push_claimed_at already set and its
-    // SELECT returns an empty set.  This replaces the racy
-    // SELECT … WHERE push_sent_at IS NULL pattern.
-    // -------------------------------------------------------------------
+    // Atomically claim a batch of pending notifications so concurrent invocations
+    // cannot double-deliver the same notification (race-condition prevention).
     const claimedAt = new Date().toISOString();
-    const staleThreshold = new Date(Date.now() - 5 * 60 * 1000).toISOString();
-
-    const { data: notifications, error: claimError } = await supabase
+    const { data: notifications, error } = await supabase
       .from("notifications")
       .update({ push_claimed_at: claimedAt })
-      .is("push_sent_at", null)
-      .or(`push_claimed_at.is.null,push_claimed_at.lt.${staleThreshold}`)
-      .select("id,user_id,title,body,action_url")
-      .order("created_at", { ascending: true })
-      .limit(100);
+      .is("push_claimed_at", null)
+      .select("id,user_id,title,body,action_url");
 
     if (claimError) {
       return res.status(500).json({ error: claimError.message });
@@ -83,29 +73,28 @@ export const dispatchPushNotifications = async (req, res, next) => {
       return res.json({ sent: 0, processed: 0 });
     }
 
+    // Batch-fetch all push subscriptions for the claimed notifications in one query.
     const userIds = [...new Set(notifications.map((n) => n.user_id))];
-
-    const { data: allSubscriptions, error: subscriptionsError } = await supabase
+    const { data: allSubscriptions, error: subError } = await supabase
       .from("push_subscriptions")
       .select("user_id,endpoint,p256dh,auth")
       .in("user_id", userIds);
 
-    if (subscriptionsError) {
-      return res.status(500).json({ error: subscriptionsError.message });
+    if (subError) {
+      return res.status(500).json({ error: subError.message });
     }
 
-    const subscriptionsByUser = new Map();
-    for (const subscription of allSubscriptions || []) {
-      if (!subscriptionsByUser.has(subscription.user_id)) {
-        subscriptionsByUser.set(subscription.user_id, []);
-      }
-      subscriptionsByUser.get(subscription.user_id).push(subscription);
+    // Group subscriptions by user_id for O(1) lookup per notification.
+    const subsByUser = {};
+    for (const sub of allSubscriptions || []) {
+      if (!subsByUser[sub.user_id]) subsByUser[sub.user_id] = [];
+      subsByUser[sub.user_id].push(sub);
     }
 
     let sent = 0;
 
     for (const notification of notifications) {
-      const subscriptions = subscriptionsByUser.get(notification.user_id) || [];
+      const subscriptions = subsByUser[notification.user_id] || [];
 
       const pushResults = await Promise.allSettled(
         subscriptions.map((subscription) =>

docs/api.md

@@ -1,8 +1,8 @@
-# 🔌 API Documentation
+# API Documentation
 
 The Peer Learning Platform primarily relies on the **Supabase JavaScript Client** for interacting with the database, and a custom **Node.js Express Backend** for secure external API interactions (like the AI assistant).
 
-## 📡 Supabase Client APIs
+## Supabase Client APIs
 
 Most data operations are performed directly from the React frontend using the `supabase-js` client. RLS (Row-Level Security) policies in the database ensure these requests are secure.
 
@@ -34,7 +34,7 @@ const sendMessage = async (sessionId: string, content: string, userId: string) =
 };
 ```
 
-## 🤖 Custom Node.js API (AI Integration)
+## Custom Node.js API (AI Integration)
 
 For operations requiring secure handling of external API keys (e.g., OpenAI/OpenRouter), requests are sent to our custom backend.
 
@@ -67,108 +67,66 @@ Generates an AI summary of a chat session.
 - Requires a valid Supabase JWT token.
 - Protected by a custom, in-house rate limiter middleware (`backend/middlewares/rateLimiter.js`) to prevent abuse.
 
-## 🔔 Cron Endpoints
+## Cron Routes (`/api/cron`)
 
-All cron endpoints require `Authorization: Bearer <CRON_SECRET>` and are subject to a 5 req/min per-IP rate limit and a 60-second per-route cooldown. Invocations within the cooldown window return `HTTP 429`.
+These endpoints are triggered by a scheduled cron job and protected by the `CRON_SECRET` environment variable.
 
----
+**Auth**: `Authorization: Bearer <CRON_SECRET>`
 
-### `POST /api/cron/dispatch-notifications`
+All cron requests must supply the `CRON_SECRET` token in the `Authorization` header. Requests without a valid `CRON_SECRET` receive a `401 Unauthorized` response.
 
-Dequeues up to 100 pending push notifications (`push_sent_at IS NULL`, oldest first) and delivers them to all registered browser push subscriptions for each recipient.
+### `POST /api/cron/dispatch-notifications`
 
-**Auth:** `Authorization: Bearer <CRON_SECRET>`
+Atomically claims a batch of pending push notifications (up to 100) and dispatches them to subscribed devices. Uses `push_claimed_at` to prevent concurrent invocations from double-delivering the same notification.
 
-**Response `200`:**
+**Response**:
 ```json
-{
-  "sent": 42,
-  "processed": 45
-}
+{ "sent": 5, "processed": 5 }
 ```
 
-| Field | Description |
-|---|---|
-| `processed` | Number of notification rows fetched (max 100) |
-| `sent` | Number of individual push deliveries that succeeded |
-
-`processed - sent` reflects push failures (expired subscriptions, VAPID misconfiguration, etc.). Individual failures are absorbed and do not block delivery to other recipients. Each notification row is stamped with `push_sent_at` regardless of delivery outcome.
-
-**Error responses:**
-
-| Status | Condition |
-|---|---|
-| `401` | Missing or malformed `Authorization` header |
-| `403` | Secret mismatch |
-| `429` | Rate limit or 60-second cooldown exceeded |
-| `500` | VAPID keys not configured, or Supabase error |
-| `503` | `CRON_SECRET` env var not set on the server |
-
----
-
 ### `POST /api/cron/reminders`
 
-Inserts `session_reminder` notifications for all sessions with `status = 'upcoming'` whose `start_time` falls within the next 14–16 minutes. Idempotent via `upsert` on `(user_id, entity_id, type)`.
-
-**Auth:** `Authorization: Bearer <CRON_SECRET>`
+Finds upcoming study sessions starting within the next 15 minutes and inserts `session_reminder` notifications for all participants.
 
-**Response `200`:**
+**Response**:
 ```json
-{ "inserted": 12 }
+{ "inserted": 3 }
 ```
 
-**Error responses:** same as `/api/cron/dispatch-notifications`.
-
----
-
 ### `POST /api/cron/mentorship-reminders`
 
-Inserts `mentorship_reminder` notifications for incomplete milestones due within 24 hours or already overdue. Notifies both the mentor and mentee. Idempotent via `upsert` on `(user_id, entity_id, type)`.
-
-**Auth:** `Authorization: Bearer <CRON_SECRET>`
+Finds incomplete mentorship milestones that are due or overdue within the next 24 hours and inserts `mentorship_reminder` notifications for mentor and mentee.
 
-**Response `200`:**
+**Response**:
 ```json
-{ "inserted": 4 }
+{ "inserted": 2 }
 ```
 
-**Error responses:** same as `/api/cron/dispatch-notifications`.
-
----
+## Notification Routes (`/api/notifications`)
 
-## 🔔 Notification Endpoints
+These endpoints support two authentication modes: `WEBHOOK_SECRET` for server-to-server calls, and a standard Supabase JWT for user-initiated calls.
 
-### `POST /api/notifications/send-push`
+**Auth**: `Authorization: Bearer <WEBHOOK_SECRET>` OR valid Supabase JWT token.
 
-Delivers a push notification to a single user's registered browser subscriptions. Stale subscriptions (HTTP 410/404 from the push service) are automatically deleted.
+Requests carrying a valid `WEBHOOK_SECRET` bypass user-level auth. Requests without a `WEBHOOK_SECRET` fall back to the standard `requireAuth` middleware which validates the Supabase JWT.
 
-**Auth:** `Authorization: Bearer <WEBHOOK_SECRET>`
+### `POST /api/notifications/send-push`
 
-> This endpoint uses a **separate secret** (`WEBHOOK_SECRET`) from the cron endpoints (`CRON_SECRET`). See the Secrets Reference in `docs/smart-notifications.md` for rotation guidance.
+Sends a browser push notification to all subscribed devices for a given `user_id`.
 
-**Request body:**
+**Request Body**:
 ```json
 {
   "user_id": "uuid",
-  "title": "string (max 100 chars)",
-  "body": "string (max 500 chars)",
-  "action_url": "/optional/path"
+  "title": "New message",
+  "body": "Alice sent you a message.",
+  "action_url": "/messages"
 }
 ```
 
-**Response `200`:**
+**Response**:
 ```json
-{
-  "sent": 1,
-  "failed": 0
-}
+{ "sent": 1, "failed": 0 }
 ```
 
-**Error responses:**
-
-| Status | Condition |
-|---|---|
-| `400` | Missing `user_id`, `title`, or `body`; payload type invalid; content too long |
-| `401` | Missing or invalid `Authorization` header |
-| `404` | No push subscriptions found for the given `user_id` |
-| `500` | VAPID keys not configured, or Supabase error |
+**Security**: Standard users may only send push notifications to themselves (IDOR prevention). Webhook callers authenticated via `WEBHOOK_SECRET` may send to any user.

docs/smart-notifications.md

@@ -317,4 +317,62 @@ VALUES (
 );
 ```
 
-The notification bell should update in realtime for the logged-in receiver.
+The notification bell should update in realtime for the logged-in receiver.
+
+## Operations
+
+### Authentication Split
+
+The notification dispatch pipeline uses two separate secrets:
+
+- **CRON_SECRET**: Authorises the scheduled `/api/cron/dispatch-notifications` and reminder endpoints. Supply as `Authorization: Bearer <CRON_SECRET>`.
+- **WEBHOOK_SECRET**: Authorises the `/api/notifications/send-push` endpoint for server-to-server calls (e.g. from Supabase Edge Functions). Supply as `Authorization: Bearer <WEBHOOK_SECRET>`.
+
+Keep these secrets separate so that a compromised `CRON_SECRET` cannot be used to send arbitrary push notifications to individual users, and vice-versa.
+
+### Queue-Depth Monitoring
+
+Use the following query to check how many notifications are still pending delivery:
+
+```sql
+SELECT COUNT(*) AS pending
+FROM notifications
+WHERE push_sent_at IS NULL
+  AND push_claimed_at IS NULL;
+```
+
+High queue depth may indicate that the `dispatch-push-notifications` cron function is not running or is erroring. Check Supabase Function logs and confirm the cron schedule is active.
+
+### Batch Cap
+
+The dispatcher atomically claims and processes up to **100** rows per invocation. If the queue consistently exceeds 100 pending rows, consider increasing the invocation frequency or raising the cap (update the `.limit(100)` call in `cronController.js`).
+
+### 60-Second Cooldown
+
+The cron schedule fires every minute. Allow at least a **60-second** cooldown between manual invocations to avoid overlapping with the scheduled run and potentially double-counting metrics.
+
+### Manual Drain
+
+To perform a **manual drain** of the notification queue (e.g. after an outage):
+
+1. Verify the cron job is paused or will not fire concurrently.
+2. Call the dispatch endpoint directly with the `CRON_SECRET`:
+
+```bash
+curl -X POST https://<your-backend>/api/cron/dispatch-notifications \
+  -H "Authorization: Bearer <CRON_SECRET>"
+```
+
+3. Repeat until the response shows `"processed": 0`.
+4. Re-enable the cron schedule.
+
+### Subscription Expiry (410 / 404)
+
+When `web-push` receives a `410 Gone` or `404 Not Found` response from a push service, it means the push subscription is no longer valid and should be removed from the database.
+
+Handle these codes by deleting the expired subscription row from `push_subscriptions`:
+
+- **410**: The subscription has been permanently cancelled by the user. Remove the record immediately.
+- **404**: The endpoint was not found. Remove the record to prevent further failed attempts.
+
+If you see a high rate of **410** or **404** errors in the push dispatch logs, users may have revoked browser notification permission. This is normal and the dead subscriptions will be pruned automatically once the expiry handler is implemented.

src/components/CreateSessionDialog.tsx

@@ -237,6 +237,7 @@ export function CreateSessionDialog({
                       <PopoverTrigger asChild>
                         <FormControl>
                           <Button
+                            type="button"
                             variant="outline"
                             className={cn(
                               "w-full pl-3 text-left font-normal bg-white/5 border-white/10 text-white hover:bg-white/10 hover:text-white",
@@ -384,4 +385,4 @@ export function CreateSessionDialog({
       </DialogContent>
     </Dialog>
   );
-}
+}