Test type</th>	Auth mechanism</th>	What Clerk sees</th></tr></thead>
Backend API tests</td>	Bearer JWT from Backend SDK</td>	Real session token, full `auth()</code> context</td></tr>`
Frontend E2E tests</td>	Sign-in via `+clerk_test</code> email + 424242</code> OTP</td>`	Real browser session, full UI context</td></tr> </tbody></table> Neither approach involves bypassing auth, mocking Clerk, or special-casing your middleware. Both test the real code path.</p> After setting this up across LucidHire’s test suite, every test that was previously blocked by auth started running cleanly. The backend tests hit real route handlers with real session data. The frontend tests navigated through the actual sign-in UI and landed on authenticated pages. Here is the same dashboard after the fix — the wall of Blocked</strong> results replaced almost entirely by green Pass</strong>:</p> </p> That is exactly what a good test suite should do.</p> Your "Server Component" Is Running on the Client (And You Have No Idea) Jameel Ahmad — Tue, 14 Apr 2026 01:00:00 +0500 You write a component. No `"use client"</code> directive. You fetch data directly, maybe even do a console.log</code> to confirm it’s running server-side. The log shows up — in your browser console.</p>` `That’s the moment. The “wait, what?” moment.</p>` `</p>` `Next.js App Router made Server Components the default, which is great. But that default comes with a catch: it’s surprisingly easy to write code you think</em> is server-only but is actually being executed on the client. Here are the real cases where this happens.</p>` Table of contents</a></h2> Case 1: No “use client” Doesn’t Mean Server Component</a></h2> The misconception:</strong> A component will render on the server simply because you didn’t add "use client"</code> to the top of the file.</p> The reality:</strong> If you import and nest that component inside a parent that is</em> a Client Component, it automatically inherits client behavior and runs in the browser.</p> // UserProfile.tsx — no "use client", so it must be a Server Component, right?</span></span> export default function</span> UserProfile</span>() {</span></span> return</span> <</span>div</span>></span>{</span>/* sensitive render logic /</span>}</span></</span>div</span>></span>;</span></span> }</span></span> </span> // Sidebar.tsx</span></span> "use client"</span>;</span></span> </span> import</span> UserProfile</span> from</span> "./UserProfile"</span>;</span> // ← now a Client Component</span></span> </span> export default function</span> Sidebar</span>() {</span></span> const</span> [</span>open</span>,</span> setOpen</span>]</span> =</span> useState</span>(</span>false</span>)</span>;</span></span> return</span> (</span></span> <</span>div</span>></span></span> <</span>UserProfile</span> /></span> {</span>/ running in the browser /</span>}</span></span> </</span>div</span>></span></span> )</span>;</span></span> }</span></span></code></pre> UserProfile</code> had no directive, but because it’s imported</em> inside a Client Component, it gets bundled into the client and runs there. Any server-only logic inside it — DB calls, secret env vars — silently breaks or gets exposed.</p> The fix:</strong> Pass the Server Component as children</code> instead of importing it directly.</p> // page.tsx (Server Component)</span></span> import</span> Sidebar</span> from</span> "./Sidebar"</span>;</span></span> import</span> UserProfile</span> from</span> "./UserProfile"</span>;</span></span> </span> export default function</span> Page</span>() {</span></span> return</span> (</span></span> <</span>Sidebar</span>></span></span> <</span>UserProfile</span> /></span> {</span>/ still a Server Component /</span>}</span></span> </</span>Sidebar</span>></span></span> )</span>;</span></span> }</span></span> </span> // Sidebar.tsx</span></span> "use client"</span>;</span></span> </span> export default function</span> Sidebar</span>({</span> children</span> }) {</span></span> const</span> [</span>open</span>,</span> setOpen</span>]</span> =</span> useState</span>(</span>false</span>)</span>;</span></span> return</span> <</span>div</span>></span>{</span>children</span>}</span></</span>div</span>></span>;</span></span> }</span></span></code></pre> Components passed as children</code> or props are not pulled into the client boundary. They stay on the server.</p> Case 2: Placing “use client” Too High in the Tree</a></h2> The misconception:</strong> You put "use client"</code> high up in your layout or page, assuming child components beneath it stay as Server Components since that’s the Next.js default.</p> The reality:</strong> The directive at the top of the tree creates a boundary that forces the entire subtree beneath it</em> to be bundled and executed on the client, completely wiping out Server Component benefits for every child.</p> // app/layout.tsx</span></span> "use client"</span>;</span> // ← placed here to use a single useState</span></span> </span> export default function</span> RootLayout</span>({</span> children</span> }) {</span></span> const</span> [</span>theme</span>,</span> setTheme</span>]</span> =</span> useState</span>(</span>"light"</span>)</span>;</span></span> return</span> (</span></span> <</span>html</span>></span></span> <</span>body</span>></span></span> {</span>/ Every single component rendered here is now a Client Component /</span>}</span></span> {</span>children</span>}</span></span> </</span>body</span>></span></span> </</span>html</span>></span></span> )</span>;</span></span> }</span></span></code></pre> Every page, every data-fetching component, every child that should be running on the server — is now running in the browser. You’ve opted your entire app out of Server Components with one misplaced directive.</p> The fix:</strong> Push "use client"</code> as deep as possible. If you only need interactivity for a theme toggle button, extract just that button</em> into its own file and mark that file as "use client"</code>.</p> // components/ThemeToggle.tsx</span></span> "use client"</span>;</span></span> </span> export default function</span> ThemeToggle</span>() {</span></span> const</span> [</span>theme</span>,</span> setTheme</span>]</span> =</span> useState</span>(</span>"light"</span>)</span>;</span></span> return</span> (</span></span> <</span>button</span> onClick</span>=</span>{()</span> =></span> setTheme</span>(</span>t</span> =></span> t</span> ===</span> "light"</span> ?</span> "dark"</span> :</span> "light"</span>)</span>}</span>></span></span> Toggle</span></span> </</span>button</span>></span></span> )</span>;</span></span> }</span></span> </span> // app/layout.tsx — no "use client" needed here</span></span> import</span> ThemeToggle</span> from</span> "@/components/ThemeToggle"</span>;</span></span> </span> export default function</span> RootLayout</span>({</span> children</span> }) {</span></span> return</span> (</span></span> <</span>html</span>></span></span> <</span>body</span>></span></span> <</span>ThemeToggle</span> /></span> {</span>/ only this is a Client Component /</span>}</span></span> {</span>children</span>} {</span>/ everything else stays on the server /</span>}</span></span> </</span>body</span>></span></span> </</span>html</span>></span></span> )</span>;</span></span> }</span></span></code></pre>Case 3: Not Separating Client and Server Utils</a></h2> The misconception:</strong> You write utility functions for backend tasks — database queries, secret lookups — and assume they’ll safely stay on the server.</p> The reality:</strong> If you accidentally import one of those server utilities into a client component, Next.js bundles that sensitive logic and ships it directly to the user’s browser.</p> // lib/utils.ts — one file for everything</span></span> export function</span> formatDate</span>(</span>date</span>:</span> Date</span>) {</span> / safe, UI logic /</span> }</span></span> export async function</span> getUserFromDb</span>(</span>id</span>:</span> string</span>) {</span> / db query, secret logic /</span> }</span></span> </span> // components/ProfileCard.tsx</span></span> "use client"</span>;</span></span> </span> import</span> {</span> formatDate</span>,</span> getUserFromDb</span> }</span> from</span> "@/lib/utils"</span>;</span></span> // ↑ getUserFromDb is now in the browser bundle</span></span></code></pre> You only meant to import formatDate</code>. But because both functions live in the same file, the entire module gets bundled — including your database logic.</p> The fix:</strong> Separate your utilities by environment. Keep server-only logic in dedicated files and protect them with the server-only</code> package.</p> // lib/server/db.ts</span></span> import</span> "server-only"</span>;</span> // ← hard build error if this gets imported client-side</span></span> </span> export async function</span> getUserFromDb</span>(</span>id</span>:</span> string</span>) {</span> / safe /</span> }</span></span> </span> // lib/utils.ts — only safe, UI-level helpers</span></span> export function</span> formatDate</span>(</span>date</span>:</span> Date</span>) {</span> / fine anywhere /</span> }</span></span></code></pre> Now if lib/server/db.ts</code> ever ends up in a client bundle, Next.js throws a build error instead of silently shipping your DB logic to users.</p> Case 4: Leaking Sensitive Data Through Props</a></h2> The misconception:</strong> You securely fetch data inside a Server Component and assume it stays secure because the fetch happened on the server.</p> The reality:</strong> If you pass that sensitive data — tokens, passwords, hidden IDs, internal pricing — down as a prop to a Client Component, it gets serialized and sent to the browser. The user can read it in full.</p> // app/dashboard/page.tsx (Server Component)</span></span> export default async function</span> DashboardPage</span>() {</span></span> const</span> user</span> =</span> await</span> db</span>.</span>query</span>(</span>`SELECT FROM users WHERE id = ?`</span>,</span> [userId])</span>;</span></span> // user contains: { id, name, email, passwordHash, stripeSecretKey, internalScore }</span></span> </span> return</span> <</span>UserCard</span> user</span>=</span>{</span>user</span>}</span> /></span>;</span> // ← passing the entire object down</span></span> }</span></span> </span> // components/UserCard.tsx</span></span> "use client"</span>;</span></span> </span> export default function</span> UserCard</span>({</span> user</span> }) {</span></span> // user.passwordHash and user.stripeSecretKey are now in the browser</span></span> return</span> <</span>div</span>></span>{</span>user</span>.</span>name</span>}</span></</span>div</span>></span>;</span></span> }</span></span></code></pre> You’re only displaying</em> user.name</code>, but the entire object was serialized into the HTML payload and shipped to the client. Anyone can inspect the network response and read the rest.</p> The fix:</strong> Pass only what the Client Component actually needs to render.</p> // app/dashboard/page.tsx</span></span> export default async function</span> DashboardPage</span>() {</span></span> const</span> user</span> =</span> await</span> db</span>.</span>query</span>(</span>`SELECT * FROM users WHERE id = ?`</span>,</span> [userId])</span>;</span></span> </span> return</span> <</span>UserCard</span> name</span>=</span>{</span>user</span>.</span>name</span>}</span> email</span>=</span>{</span>user</span>.</span>email</span>}</span> /></span>;</span> // ← only safe fields</span></span> }</span></span></code></pre> Never pass a raw database object to a Client Component. Treat the prop boundary the same way you’d treat an API response — intentionally shape what leaves the server.</p> Edge Case: Server Actions Aren’t Private Functions</a></h2> Server Actions do execute on the server, so this section is a bit different — your code does</em> run server-side. But there’s a fundamental misunderstanding about what that means for security.</p> Adding “use server” Doesn’t Make a Function Private</a></h3> The misconception:</strong> You add "use server"</code> to a function thinking it’s a strict rule to “run this private utility on the server” — an internal function the outside world can’t touch.</p> The reality:</strong> "use server"</code> creates a public-facing POST endpoint</strong>. The client can invoke it at will. If you don’t validate and authorize inside the action itself, you’ve left a door wide open.</p> // app/actions.ts</span></span> "use server"</span>;</span></span> </span> export async function</span> deleteUser</span>(</span>userId</span>:</span> string</span>) {</span></span> // No auth check. No ownership check.</span></span> await</span> db</span>.</span>delete</span>(</span>"users"</span>, {</span> id</span>:</span> userId</span> }</span>)</span>;</span> // ← anyone can call this</span></span> }</span></span></code></pre> This action is reachable via a POST request from any client — your app, someone else’s browser tab, a curl command. The fact that it runs on your server doesn’t make it safe; it makes it a publicly accessible API that does destructive work.</p> The fix:</strong> Treat every Server Action like a public API route. Verify authentication and authorization inside the action on every single call.</p> "use server"</span>;</span></span> </span> import</span> {</span> auth</span> }</span> from</span> "@/lib/auth"</span>;</span></span> </span> export async function</span> deleteUser</span>(</span>userId</span>:</span> string</span>) {</span></span> const</span> session</span> =</span> await</span> auth</span>()</span>;</span></span> if</span> (</span>!</span>session)</span> throw</span> new</span> Error</span>(</span>"Unauthorized"</span>)</span>;</span></span> if</span> (session</span>.</span>user</span>.</span>role</span> !==</span> "admin"</span>)</span> throw</span> new</span> Error</span>(</span>"Forbidden"</span>)</span>;</span></span> </span> await</span> db</span>.</span>delete</span>(</span>"users"</span>, {</span> id</span>:</span> userId</span> }</span>)</span>;</span></span> }</span></span></code></pre> Never assume a Server Action is protected because it lives in your codebase. Assume every action is reachable by anyone and validate accordingly.</p> The Mental Model That Actually Helps</a></h2> Stop thinking of Server vs. Client as a property of individual files. Think of it as two separate execution environments</strong>, and your code lives in whichever one its import chain puts it in.</p> "use client"</code> doesn’t mark a component as client-only. It marks a boundary</strong> — the point where the server tree ends and the client bundle begins.</li> Everything imported inside</em> a Client Component becomes client code, regardless of its own directives.</li> Everything passed as props or children</em> keeps its original context.</li> Server Actions are public endpoints, not private functions.</li> </ul> Once that clicks, the mask reveal makes sense. Your “Server Component” was always the client. You just hadn’t pulled it off yet.</p> How TestSprite Helped Me Find a Silent Polar Checkout Bug (and How I Fixed It) Jameel Ahmad — Sun, 12 Apr 2026 14:00:00 +0500 I have been building Lucid Hire</strong>, a Next.js recruiter dashboard with Clerk</strong> auth, Neon</strong> Postgres, and Polar</strong> for subscriptions. The billing page lets recruiters click Upgrade to Pro</strong> and navigate to Polar-hosted checkout. In manual testing I had tunneling and env quirks, so I leaned on TestSprite</strong>—an MCP-connected E2E runner—to exercise the full app through a real browser session.</p> One case kept failing: TC013</strong>, “Billing page remains usable after returning from external checkout.” The report was blunt: hitting /api/billing/checkout?plan=pro</code> returned HTTP 500</strong> with a generic browser error page—no JSON, no stack trace in the UI.</p> </p> This post is about how that failure was actually a gift: TestSprite reproduced a path I had not fully validated, and chasing it led to a concrete bug in how we integrated Polar—not “Polar is down,” but our route crashing before the SDK could even run</strong>.</p> Table of contents</a></h2> What TestSprite reported</a></h2> TestSprite generates a frontend test plan, runs Playwright-style flows against my local app (via a tunnel), and writes a report under testsprite_tests/tmp/raw_report.md</code>. For TC013</strong>, the relevant excerpt looked like this in spirit:</p> The automation navigated to /api/billing/checkout?plan=pro</code></strong> (same as our real Upgrade</strong> button).</li> The browser showed “This page isn’t working”</strong> / HTTP ERROR 500</strong>.</li> No redirect to Polar, so the test correctly marked a failure</strong>.</li> </ul> That told me the bug was server-side</strong> in our checkout API route, not a flaky click in the billing UI.</p> Following the trail to src/app/api/billing/checkout/route.ts</code></a></h2> Our billing client triggers checkout with a full-page navigation—simple and intentional:</p> const</span> startUpgrade</span> =</span> (</span>plan</span>:</span> "</span>pro</span>"</span> \|</span> "</span>max</span>"</span>)</span> =></span> {</span></span> setLoadingPlan</span>(plan)</span>;</span></span> window</span>.</span>location</span>.</span>href</span> =</span> `/api/billing/checkout?plan=</span>${</span>plan</span>}</span>`</span>;</span></span> };</span></span></code></pre> So every upgrade goes through GET /api/billing/checkout</code></strong>. I opened the route handler next.</p> Originally, the route used Checkout</code> from @polar-sh/nextjs</code></strong>, which wraps @polar-sh/sdk</code></strong> and builds a checkout session from query parameters. On the surface that is the “official” integration. The problem was what happened before</strong> Polar’s API was called.</p> The mystery of the blank 500</a></h2> Inside @polar-sh/nextjs</code>, the checkout handler does something like this (simplified from the published package):</p> const</span> success</span> =</span> successUrl</span> ?</span> new</span> URL</span>(successUrl)</span> : void</span> 0</span>;</span></span> if</span> (success</span> &&</span> includeCheckoutId)</span> {</span></span> success</span>.</span>searchParams</span>.</span>set</span>(</span>"checkoutId"</span>,</span> "{CHECKOUT_ID}"</span>)</span>;</span></span> }</span></span> try</span> {</span></span> const</span> result</span> =</span> await</span> polar</span>.</span>checkouts</span>.</span>create</span>(</span>{</span> /* ... /</span> }</span>)</span>;</span></span> return</span> NextResponse</span>.</span>redirect</span>(redirectUrl</span>.</span>toString</span>())</span>;</span></span> }</span> catch</span> (error)</span> {</span></span> console</span>.</span>error</span>(error)</span>;</span></span> return</span> NextResponse</span>.</span>error</span>()</span>;</span></span> }</span></span></code></pre> Two important details:</p> new URL(successUrl)</code> runs outside the try</code> block.</strong> In JavaScript, new URL("/dashboard/settings/billing")</code> throws</strong>—relative URLs are invalid without a base. So if POLAR_SUCCESS_URL</code> was unset in a way that still led to bad input, or was documented as a “path only” value, the handler could throw before try</code></strong> → Next.js responds with an unhelpful 500</strong> and no JSON body.</p> </li> When the Polar API failed, the helper returned NextResponse.error()</code>.</strong> That is also an opaque 500</strong> from the browser’s point of view. TestSprite (and users) only see “something broke.”</p> </li> </ol> Separately, our README listed POLAR_ACCESS_TOKEN</code></strong> and product IDs but never POLAR_SUCCESS_URL</code></strong>. Locally I had been “fine” until the exact combination of tunnel + env + navigation reproduced the crash in CI-style E2E.</p> How TestSprite helped beyond “checkout is broken”</a></h2> Without TestSprite, I might have assumed:</p> “Polar credentials are wrong,” or</li> “Test user is not allowed to checkout,” or</li> “Clerk session is missing.”</li> </ul> The report narrowed it: authenticated flows passed</strong> (billing page, plan copy, other cases), but the API route itself</strong> returned 500 when used like a real user (full navigation</strong> to the API URL). That pushed me to read the route + Polar adapter</strong>, not redo Clerk for the tenth time.</p> So the value was not only automation—it was a reproducible, user-shaped repro</strong> attached to logs and video links in the TestSprite dashboard.</p> The fix: own the checkout flow and make URLs safe</a></h2> I stopped delegating to @polar-sh/nextjs</code>’s Checkout()</code> for this route and called polar.checkouts.create()</code></strong> from @polar-sh/sdk</code></strong> directly, with:</p> A resolver that always produces a valid absolute success URL</strong></li> A try/catch</code> that returns JSON with a real error message</strong> (HTTP 502) when Polar rejects the request</li> </ol> 1. Resolve POLAR_SUCCESS_URL</code> safely</a></h3> Polar needs an absolute</strong> success URL. If the env var is missing, we default to returning the user to billing. If it is a relative path, we resolve it against NEXT_PUBLIC_APP_URL</code>, VERCEL_URL</code>, or the incoming request origin:</p> function</span> resolveCheckoutSuccessUrl</span>(</span>request</span>:</span> NextRequest</span>)</span>:</span> URL</span> {</span></span> const</span> raw</span> =</span> process</span>.</span>env</span>.</span>POLAR_SUCCESS_URL</span>?.</span>trim</span>()</span>;</span></span> const</span> origin</span> =</span></span> process</span>.</span>env</span>.</span>NEXT_PUBLIC_APP_URL</span>?.</span>replace</span>(</span>/\/</span>$</span>/</span>,</span> ""</span>)</span> \|\|</span></span> (process</span>.</span>env</span>.</span>VERCEL_URL</span> ?</span> `https://</span>${</span>process</span>.</span>env</span>.</span>VERCEL_URL</span>}</span>`</span> :</span> null</span>)</span> \|\|</span></span> request</span>.</span>nextUrl</span>.</span>origin</span>;</span></span> </span> if</span> (</span>!</span>raw)</span> {</span></span> return</span> new</span> URL</span>(</span>"/dashboard/settings/billing"</span>,</span> origin)</span>;</span></span> }</span></span> </span> try</span> {</span></span> return</span> new</span> URL</span>(raw)</span>;</span></span> }</span> catch</span> {</span></span> const</span> path</span> =</span> raw</span>.</span>startsWith</span>(</span>"/"</span>)</span> ?</span> raw</span> :</span> `/</span>${</span>raw</span>}</span>`</span>;</span></span> return</span> new</span> URL</span>(path</span>,</span> origin)</span>;</span></span> }</span></span> }</span></span></code></pre> Then we append Polar’s checkoutId={CHECKOUT_ID}</code></strong> placeholder the same way the official helper does:</p> const</span> successUrl</span> =</span> resolveCheckoutSuccessUrl</span>(request)</span>;</span></span> successUrl</span>.</span>searchParams</span>.</span>set</span>(</span>"checkoutId"</span>,</span> "{CHECKOUT_ID}"</span>)</span>;</span></span></code></pre>2. Create the session and redirect—or return a clear error</a></h3> const</span> polar</span> =</span> new</span> Polar</span>(</span>{</span></span> accessToken</span>,</span></span> server</span>:</span> polarServerFromEnv</span>()</span>,</span></span> }</span>)</span>;</span></span> </span> try</span> {</span></span> const</span> result</span> =</span> await</span> polar</span>.</span>checkouts</span>.</span>create</span>(</span>{</span></span> products</span>:</span> [productId]</span>,</span></span> successUrl</span>:</span> decodeURI</span>(successUrl</span>.</span>toString</span>())</span>,</span></span> externalCustomerId</span>:</span> organization</span>.</span>id</span>,</span></span> customerEmail</span>:</span> appUser</span>.</span>email</span>,</span></span> customerName</span>:</span> appUser</span>.</span>name</span> ??</span> undefined</span>,</span></span> metadata</span>:</span> {</span> orgId</span>:</span> organization</span>.</span>id</span> },</span></span> }</span>)</span>;</span></span> </span> return</span> NextResponse</span>.</span>redirect</span>(result</span>.</span>url)</span>;</span></span> }</span> catch</span> (error)</span> {</span></span> console</span>.</span>error</span>(</span>"[billing/checkout] Polar API error:"</span>,</span> error)</span>;</span></span> return</span> NextResponse</span>.</span>json</span>(</span></span> {</span> error</span>:</span> checkoutErrorMessage</span>(error)</span> },</span></span> {</span> status</span>:</span> 502</span> },</span></span> )</span>;</span></span> }</span></span></code></pre> After this change:</p> Misconfiguration</strong> (wrong token, wrong sandbox vs production product id) still fails—but the response is JSON with a message</strong>, and the server log has the Polar error. TestSprite (or curl) can surface that instead of a blank chrome error page.</li> Missing or relative POLAR_SUCCESS_URL</code></strong> no longer crashes the process on new URL()</code>.</li> </ul> What I learned</a></h2> E2E tools like TestSprite</strong> are not only for “click happy paths.” They excel at boring but exact repros</strong>: same URL, same query string, same navigation semantics as production.</li> Third-party adapters</strong> (@polar-sh/nextjs</code>) save time until they hide thrown errors</strong> or parse env in ways that assume perfect configuration</strong>. Sometimes owning the ten lines of SDK calls buys you observability</strong> and control</strong>.</li> POLAR_SUCCESS_URL</code> should be documented</strong> next to tokens and product IDs: absolute URL preferred; if you use a path, we now resolve it—but you should still set NEXT_PUBLIC_APP_URL</code></strong> (or rely on request.nextUrl.origin</code> in dev) so the base is correct behind proxies and tunnels.</li> </ul> Fixing "No Wi-Fi Adapter Found" on Fedora with Intel AX201 Jameel Ahmad — Wed, 25 Feb 2026 20:10:00 +0500 I was working on my Lenovo ThinkPad X13 Yoga Gen 2 running Fedora Linux 43 when suddenly the Wi-Fi disappeared. The settings showed a dreaded message: “No Wi-Fi Adapter Found”</strong>. What made it even more frustrating was that the hardware was clearly there—I had an Intel Wi-Fi 6 AX201 card installed.</p> </p> After some investigation, I discovered this was a common issue with Intel AX201 wireless cards on Linux, particularly affecting Fedora users. The driver would work sometimes but fail to initialize properly on boot.</p> Table of contents</a></h2> Diagnosing the Problem</a></h2> First, I needed to understand what was actually happening. I ran some diagnostic commands to check if the hardware was detected:</p> lspci</span> -nnk</span> \|</span> grep</span> -iA3 network</span></span></code></pre> Output showed my card was detected:</p> 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:a0f0] (rev 20)</span></span> Subsystem: Intel Corporation Device [8086:0070]</span></span> Kernel modules: iwlwifi</span></span></code></pre> The hardware was there, and the iwlwifi</code> driver module was available. So what was the issue?</p> The Real Culprit: Driver Initialization Timeout</a></h2> I checked the kernel messages to see what was happening during boot:</p> sudo</span> dmesg</span> \|</span> grep</span> -i iwl</span></span></code></pre> Buried in the output was the critical error:</p> iwlwifi 0000:00:14.3: probe with driver iwlwifi failed with error -110</span></span></code></pre> Error -110</strong> is a timeout error. The driver was trying to communicate with the Wi-Fi card but couldn’t establish a connection within the expected time frame. This is a well-known issue with Intel AX201 cards on Linux systems.</p> I also verified that the driver module was loaded:</p> lsmod</span> \|</span> grep</span> -i iwl</span></span> # Output:</span></span> iwlwifi</span> 589824 0</span></span> cfg80211</span> 1544192 1</span> iwlwifi</span></span></code></pre> The module was loaded, but it just couldn’t talk to the hardware properly.</p> The Temporary Solution That Revealed the Root Cause</a></h2> At first, I tried reinstalling the firmware:</p> sudo</span> dnf reinstall iwl</span></span>-firmware</span></span> sudo</span> reboot</span></span></code></pre> This worked! After the reboot, Wi-Fi appeared and connected successfully. But when I rebooted again, the problem came back. The Wi-Fi would disappear on every other boot.</p> This intermittent behavior told me something important: the firmware and driver could</em> work, but they weren’t being initialized properly during the boot process.</p> The Permanent Fix: A Multi-Layered Approach</a></h2> After researching and testing, I found that a combination of solutions was needed to make the Wi-Fi work reliably across all reboots.</p> 1. Reinstall the Firmware</a></h3> First, ensure the Intel wireless firmware is properly installed:</p> sudo</span> dnf reinstall iwl</span>*</span>-firmware</span></span></code></pre>2. Add the Driver to Initramfs</a></h3> The initramfs (initial RAM filesystem) is loaded early in the boot process. By adding the iwlwifi driver to it, we ensure it’s available when the system needs it:</p> echo</span> 'add_drivers+=" iwlwifi "'</span> \|</span> sudo</span> tee /etc/dracut.conf.d/iwlwifi.conf</span></span> sudo</span> dracut -f --regenerate-all</span></span></code></pre>3. Disable Power Management</a></h3> The timeout error often occurs because aggressive power management prevents the driver from initializing properly. Disabling power saving for the Wi-Fi module fixes this:</p> echo</span> "options iwlwifi power_save=0"</span> \|</span> sudo</span> tee /etc/modprobe.d/iwlwifi.conf</span></span></code></pre>4. Rebuild Initramfs Again</a></h3> After adding the power management configuration, rebuild the initramfs to include these settings:</p> sudo</span> dracut -f --regenerate-all</span></span></code></pre>5. Create a Systemd Service as a Backup</a></h3> As an extra layer of reliability, I created a systemd service that forces the driver to reload on every boot:</p> sudo</span> tee /etc/systemd/system/iwlwifi-reload.service</span> <<</span> 'EOF'</span></span> [Unit]</span></span> Description=Reload iwlwifi module</span></span> After=network-pre.target</span></span> Before=network.target</span></span> </span> [Service]</span></span> Type=oneshot</span></span> ExecStart=/usr/sbin/modprobe -r iwlwifi</span></span> ExecStart=/usr/sbin/modprobe iwlwifi</span></span> RemainAfterExit=yes</span></span> </span> [Install]</span></span> WantedBy=multi-user.target</span></span> EOF</span></span> </span> sudo</span> systemctl enable iwlwifi-reload.service</span></span></code></pre>6. Final Reboot</a></h3> sudo</span> reboot</span></span></code></pre>Why This Combination Works</a></h2> This multi-layered approach ensures Wi-Fi reliability through:</p> Firmware reinstallation</strong>: Ensures the latest Intel AX201 firmware is available</li> Initramfs configuration</strong>: Makes the driver available early in the boot process</li> Power management disabled</strong>: Prevents timeout errors during initialization</li> Systemd service</strong>: Provides a safety net by forcing module reload if other methods fail</li> </ul> The combination handles edge cases across kernel updates, firmware updates, and various boot scenarios.</p> Verification</a></h2> After rebooting, you can verify everything is working:</p> # Check if the service is active</span></span> systemctl</span> status iwlwifi-reload.service</span></span> </span> # Check if power_save is disabled</span></span> cat</span> /etc/modprobe.d/iwlwifi.conf</span></span> </span> # Verify Wi-Fi adapter is detected</span></span> nmcli</span> device status</span></span></code></pre>Conclusion</a></h2> The Intel Wi-Fi 6 AX201 is an excellent wireless card, but its Linux drivers can be finicky on Fedora. The error -110 timeout issue is frustrating because it’s intermittent—sometimes working, sometimes not.</p> By combining proper initramfs configuration, power management tweaks, and a systemd service fallback, I’ve achieved reliable Wi-Fi functionality across all reboots. This solution should persist across system updates and kernel changes.</p> If you’re experiencing similar issues with Intel wireless cards on Fedora or other Linux distributions, this comprehensive approach should help you achieve stable Wi-Fi connectivity.</p> Overcoming YouTube Authentication Hurdles with yt-dlp Jameel Ahmad — Fri, 30 Jan 2026 03:02:00 +0500 For anyone who loves managing their own media library, yt-dlp</strong> is the gold standard. It is an incredibly powerful command-line tool that can download video and audio from thousands of sites with surgical precision. Whether you want a specific resolution or just a high-quality MP3, yt-dlp handles it with ease.</p> </p> However, as platforms like YouTube tighten their security to prevent botting, we often run into “Sign in to confirm you’re not a bot” errors or age-restriction blocks. While yt-dlp has a built-in feature to grab cookies directly from your browser, modern security updates have made this process surprisingly frustrating.</p> Table of contents</a></h2> The “Database Locked” Headache</a></h2> Usually, you would try to use your browser’s session by adding --cookies-from-browser edge</code> to your command. But more often than not, you’ll be greeted by this annoying error:</p> Extracting cookies </span>from</span> edge</span></span> ERROR: Could not copy Chrome cookie database. See </span>[</span>https</span>:</span>//</span>github.com</span>/</span>yt</span>-</span>dlp</span>/</span>yt</span>-</span>dlp</span>/</span>issues</span>/</span>7271</span>](</span>https:</span>//</span>github.com</span>/</span>yt</span>-</span>dlp</span>/</span>yt</span>-</span>dlp</span>/</span>issues</span>/</span>7271</span>)</span> for</span> more info</span></span> </span></code></pre> This happens because Chromium-based browsers (like Edge, Chrome, and Brave) lock their cookie database file while the browser is open. Even if you close the window, background processes often keep the file “in use,” preventing yt-dlp from reading your login session.</p> The Solution: Manual Cookie Extraction</a></h2> The most reliable way to bypass this without constantly closing your browser is to use a cookie export extension. This gives yt-dlp a static “snapshot” of your login session that it can read freely.</p> 1. Install the Extension</a></h3> I use an extension called “Get cookies.txt LOCALLY”</strong>. It’s lightweight and doesn’t send your data to any external servers.</p> Install it from the Chrome/Edge Web Store.</li> Open YouTube and make sure you are logged in.</li> Click the extension icon and export your cookies as a .txt</code> file.</li> </ul> 2. Prepare Your Folder</a></h3> Save the file (e.g., cookies.txt</code>) directly into the folder where you run your commands. In my case, that is C:\Users\jameel\music</code>.</p> 3. Run the Correct Command</a></h3> Now, instead of telling yt-dlp to look into the browser, we point it directly to our text file using the --cookies</code> flag:</p> yt</span>-</span>dlp </span>--</span>js</span>-</span>runtimes node </span>--</span>remote</span>-</span>components ejs:github </span>--</span>cookies cookies.txt </span>-</span>x </span>--</span>audio</span>-</span>format mp3 </span>--</span>audio</span>-</span>quality </span>0</span> "media_link_to_be_download"</span></span> </span></code></pre>Why This Works Better</a></h3> No Conflicts:</strong> It doesn’t matter if Edge is open, closed, or running 50 tabs; the text file is always accessible.</li> Consistency:</strong> This method works even when browser updates change how internal databases are encrypted.</li> Bypass Captchas:</strong> Since the file contains your actual “logged-in” session, YouTube treats the request as coming from a verified user.</li> </ul> A Note on Security</a></h2> Your cookies.txt</code> file is essentially a temporary key to your account. Never share this file with anyone else! Once you are done with your downloads, it is a good habit to delete the text file or move it to a secure location.</p> How I Fixed Missing H.264 Codecs on a Fresh Fedora Install Jameel Ahmad — Fri, 09 Jan 2026 01:43:00 +0500 I freshly installed Fedora Linux Workstation 43 on my PC and tried to play a video. The video played, but it was blank. It turned out there was an issue with the missing video decoder required to run this video: H.264</strong>.</p> </p> The issue is that this encoder is proprietary and does not come with Fedora by default due to licensing restrictions. To fix this, I had to dive into the world of FFmpeg and package management.</p> Table of contents</a></h2> The Mystery of the “Missing” FFmpeg</a></h2> There is a huge library of multimedia encoders and decoders out there called FFmpeg. I needed to check if FFmpeg was installed in Fedora and if it included the H.264 encoder.</p> I used the command:</p> dnf</span> list installed</span> \|</span> grep</span> ffmpeg</span></span> </span></code></pre> Surprisingly, I got nothing. However, when I ran ffmpeg</code> directly in the terminal, the command worked! It was strange to me how a command-line utility could be available even when it didn’t appear as “installed” in my package list.</p> Finding the Culprit: ffmpeg-free</a></h2> It turns out Fedora comes with a “free” version of FFmpeg that excludes proprietary encoders. To solve the mystery, I first checked where the command was running from:</p> which</span> ffmpeg</span></span> # Output: /usr/bin/ffmpeg</span></span> </span></code></pre> Then, I passed this path to RPM to check which package exactly owned this file:</p> rpm</span> -qf /usr/bin/ffmpeg</span></span> </span></code></pre> The result: ffmpeg-free-7.1.2-2.fc43.x86_64</code>.</p> This confirmed that the “free” version was installed, which lacks the H.264 proprietary encoder.</p> The Solution: Swapping to RPM Fusion</a></h2> To fix this, I needed to enable the RPM Fusion</strong> repositories and swap the limited version for the full one.</p> 1. Enable Repositories</a></h3> First, I enabled the free and non-free RPM Fusion repositories:</p> sudo</span> dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-</span>$(</span>rpm</span> -E %fedora</span>)</span>.noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-</span>$(</span>rpm</span> -E %fedora</span>)</span>.noarch.rpm</span></span> </span></code></pre>2. Swap the Packages</a></h3> Then, I used this command to install the proprietary version of FFmpeg and remove the pre-installed free one:</p> sudo</span> dnf swap ffmpeg-free ffmpeg --allowerasing</span></span> </span></code></pre>Fixing Lag and Crashes</a></h2> The codec was installed successfully and the video played, but I hit another problem: the video was lagging heavily and the player sometimes crashed.</p> The default video player tries to find the right codec automatically, but sometimes it tries to roll back to the “free” version or struggles with dependencies. To enforce all multimedia apps to use the preferred encoding packages, I ran:</p> sudo</span> dnf update @multimedia --setopt="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin</span></span> </span></code></pre>What does this command do?</a></h3> @multimedia</code></strong>: This is the group in which all multimedia-related apps are grouped by Fedora.</li> install_weak_deps=False</code></strong>: This prevents the system from pulling back in the limited “free” versions as optional dependencies.</li> --exclude=PackageKit-gstreamer-plugin</code></strong>: This stops the GUI software store from interfering with our manual codec setup.</li> </ul> After running this, the H.264 videos played perfectly smooth!</p>

Jameel Ahmad

Record any Privacy Protected Screen like Snapchat, Netflix and other Social & OTT Platforms

Jameel Ahmad — Wed, 22 Apr 2026 02:22:00 +0500

I was casually scrolling Snapchat one night when a friend sent me a private video marked “Not allowed to share.” The app promised it would notify the sender if I tried to screen-record it. I got curious — does this protection actually hold up?

Being a Fedora guy, I decided to test it the Linux way. What I discovered was surprisingly simple and works on Snapchat, Netflix, Disney+, Prime Video, and pretty much any social or OTT platform that tries to block recording. No root, no cracked apps, no shady tools — just a virtual machine and OBS.

Let me walk you through the whole story and turn it into a complete tutorial so you can try it yourself (for testing and educational purposes only, of course!).

Why This Trick Even Works (The Simple Explanation)</a></h2>
Most DRM and “anti-recording” protections (like Snapchat’s notification system or Netflix’s screen-block) only look inside the operating system where the app is running. They check for screen-recording APIs, overlays, or running processes in that same environment.
When you run the app inside a virtual machine (the “guest” OS), it has zero knowledge of what’s happening on your real computer (the “host” or “master” OS). The guest thinks it’s on a normal device. Your recording tool runs completely outside the guest, so the DRM never sees it. It’s like watching someone through a one-way mirror — they have no idea you’re there.
That’s the whole magic. Now let’s do it step by step.
What You’ll Need</a></h2>

A Fedora Linux machine (I used Fedora 43 Workstation)</li>
GNOME Boxes (a virtualization tool)</li>
OBS Studio (free and excellent screen recorder)</li>
About 15 minutes of your time</li> </ul>
Step-by-Step Tutorial: Record Any Protected Screen</a></h2>
1. Prepare Your Host Fedora System</a></h3>
Open a terminal and install the virtualization tools and OBS:
`sudo dnf install gnome-boxes qemu-kvm libvirt virt-manager obs-studio sudo systemctl enable --now libvirtd</code></pre>`
2. Create an Isolated Virtual Machine</a></h3>

Open GNOME Boxes.</li>
Click Create a new virtual machine.</li>
Choose the latest Fedora Workstation ISO (or let Boxes download it for you).</li>
Give the VM 4 GB RAM and 4 CPU cores (plenty for Snapchat or Netflix).</li>
Click Create and let it install a fresh Fedora inside the window.</li> </ol>
Once the VM boots up, you now have a completely separate Linux desktop running inside your main computer.
3. Install the App Inside the Virtual Machine</a></h3>
Inside the guest VM, install the app you want to record. For Snapchat (official Flatpak):
`sudo dnf install flatpak flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo flatpak install flathub org.snapchat.Snapchat</code></pre> For Netflix or any other platform, just open Firefox inside the VM and go to the website. Log in and open the private/protected video or content you want to capture.`
4. Record from the Host OS Using OBS</a></h3>
Now switch back to your real (host) Fedora desktop:

Open OBS Studio.</li>
Create a new Scene.</li>
Add a new source → Window Capture.</li>
Select the GNOME Boxes window (your virtual machine).</li>
(Optional) Turn on “Capture Cursor” if you want the mouse pointer.</li>
Set your recording quality (I use MP4, 1080p or 1440p, 8000–15000 kbps bitrate).</li>
Hit Start Recording.</li> </ol>
Go back to the VM, play the private Snapchat video / Netflix show / whatever protected content.
Watch what happens:

The video plays in full quality inside the VM.</li>
OBS captures everything perfectly on your host.</li>
The sender or the platform gets zero notification or warning.</li> </ul>
I tried it with a Snapchat private snap — my friend never got the “screen recorded” message. Same thing with Netflix: no black screen, no DRM block.
5. Save and Stop</a></h3>
When you’re done, stop the recording in OBS. Your captured video is saved on the host machine, completely outside the VM’s world.
This Works on Almost Any Platform</a></h2>
I’ve personally tested it on:

Snapchat private snaps and stories</li>
Facebook & Instagram</li>
Netflix (web version)</li>
Disney+</li>
Amazon Prime Video</li> </ul>
As long as the protection lives inside the guest OS, it stays blind to the host recorder.

How I Fixed Testsprite Tests Getting Blocked by Clerk Auth in Next.js

Jameel Ahmad — Sat, 18 Apr 2026 01:43:00 +0500

I was working on LucidHire</a> and decided to run a full test sweep using Testsprite — both backend API tests and frontend E2E tests. Nearly everything came back blocked. The backend tests were hitting 401 Unauthorized on every API route. The frontend tests were failing even earlier: Clerk’s sign-in form was rejecting the test credentials entirely, so the runner couldn’t even log in to reach the pages it needed to test.
Two separate problems, two separate fixes. This post covers both.
Table of contents</a></h2>
The Problem: Everything Is Blocked</a></h2>
The two failure modes look different but share the same root cause — Clerk has no idea these requests are coming from a test runner and not a real user.
Backend tests hit your API routes directly. Your Next.js middleware runs clerkMiddleware()</code>, which checks for a valid session token. Since Testsprite makes raw HTTP calls with no browser session and no Bearer token, Clerk blocks the request before it ever reaches your route handler.
GET /api/jobs → 401 Unauthorized POST /api/candidates → 401 Unauthorized PATCH /api/interviews/:id → 401 Unauthorized</code></pre> Frontend tests have a different problem. Testsprite launches a browser, navigates to your sign-in page, and tries to log in with test credentials. But if those credentials are a made-up email and password, Clerk will either reject them or — if email verification is enabled — get stuck waiting for a verification code that never arrives. The test runner sits at the login screen forever and never reaches the actual UI it needs to test. Here is what the Testsprite dashboard looked like before any fix — almost every frontend test case showing Blocked: 
Why Not Just Bypass Auth?</a></h2>
The quick fix is to add a secret header check in your middleware and skip Clerk when it matches. That works for backend tests, but it has real downsides:

Your route handlers call auth()</code> to get userId</code>, orgId</code>, etc. With a bypass, those calls return null</code> or break entirely</li>
You have to mock auth()</code> separately, which adds more complexity</li>
Your tests are no longer exercising the same code path real users hit</li> </ul> With a real token, none of that is a problem. The token passes through Clerk’s normal verification, auth()</code> returns a real session object, and your route handlers run exactly as they would in production. That is the goal.Part 1: Fixing Backend Tests with the Clerk Backend SDK</a></h2> Clerk’s Backend SDK lets you create sessions and generate signed JWTs for any user in your Clerk application — no browser, no OAuth dance, no cookie required. Step 1: Install the SDK</a></h3> npm install @clerk/backend</code></pre>Step 2: Create a Dedicated Test User</a></h3> Go to your Clerk Dashboard</a>, open your application, and create a dedicated test user — something like testsprite@yourdomain.com</code>. Copy the user’s ID from the dashboard (it looks like user_2xyz...</code>). Never use a real user’s ID for testing. A dedicated test user keeps things isolated and makes it easy to spot test-generated data in your database. Step 3: Add Environment Variables</a></h3> Add these to your .env.local</code> and your CI environment: CLERK_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxx CLERK_TEST_USER_ID=user_2xxxxxxxxxxxxxxxxxxx</code></pre>Step 4: Write the Global Setup File</a></h3> Create a global setup file that runs once before all your tests, generates a real JWT, and stores it in process.env</code> so every test can access it. // testsprite.setup.ts import { createClerkClient } from "@clerk/backend"; const clerk = createClerkClient({ secretKey: process.env.CLERK_SECRET_KEY!, }); export async function setup() { // Create a real Clerk session for the test user const session = await clerk.sessions.createSession({ userId: process.env.CLERK_TEST_USER_ID!, }); // Get a signed JWT from that session const { jwt } = await clerk.sessions.getToken(session.id, "session_token"); // Make it available to all test files process.env.TEST_AUTH_TOKEN = jwt; console.log("✅ Clerk test token generated, expires:", new Date(session.expireAt)); }</code></pre>Step 5: Configure Testsprite to Use the Setup</a></h3> Point Testsprite at your setup file in its config: // testsprite.config.ts import { defineConfig } from "testsprite"; export default defineConfig({ globalSetup: "./testsprite.setup.ts", baseURL: "http://localhost:3000", });</code></pre>Step 6: Use the Token in Your Test Requests</a></h3> Now every test request just grabs the token from process.env</code>: // tests/api/jobs.test.ts const res = await fetch("http://localhost:3000/api/jobs", { method: "GET", headers: { Authorization: `Bearer ${process.env.TEST_AUTH_TOKEN}`, "Content-Type": "application/json", }, }); expect(res.status).toBe(200);</code></pre> No bypasses, no mocks, no workarounds. Clerk sees a real Bearer token, verifies it, and your route handler gets a fully populated auth()</code> context. What This Looks Like End-to-End</a></h3> Global setup runs → SDK creates a Clerk session for your test user, fetches a signed JWT</li> Token stored → process.env.TEST_AUTH_TOKEN</code> is set for the entire test process</li> Test runs → each request includes Authorization: Bearer <token></code></li> Clerk middleware → verifies the token, sets the session context, passes the request through</li> Route handler → auth()</code> returns { userId: "user_2xyz...", ... }</code> just like in production</li> Test assertion → checks the actual response from your real business logic</li> </ol> Handling Token Expiry in Long Test Runs</a></h3> Clerk tokens expire after about an hour by default. For most test suites this is fine, but if you have very long-running pipelines you may want to refresh the token per file using a beforeAll</code> block: // tests/api/jobs.test.ts import { createClerkClient } from "@clerk/backend"; const clerk = createClerkClient({ secretKey: process.env.CLERK_SECRET_KEY! }); beforeAll(async () => { const session = await clerk.sessions.createSession({ userId: process.env.CLERK_TEST_USER_ID!, }); const { jwt } = await clerk.sessions.getToken(session.id, "session_token"); process.env.TEST_AUTH_TOKEN = jwt; });</code></pre>One Thing to Watch Out For</a></h3> clerk.sessions.createSession()</code> requires a Clerk Pro plan or above. If you call it on a free plan, you will get a 402 Payment Required</code> error. Also make sure CLERK_SECRET_KEY</code> starts with sk_test_...</code> — the publishable key (pk_test_...</code>) is frontend-only and will not work here. Part 2: Fixing Frontend Tests with Clerk Test Credentials</a></h2> Frontend tests are a different challenge. Testsprite spins up a real browser and navigates through your actual UI. That means it has to go through your sign-in page and successfully authenticate before it can test anything behind the auth wall. The problem is that Clerk’s email verification flow — OTP codes, magic links — is designed to be interactive. A test runner can’t check a real inbox. Clerk solves this with special test email addresses that bypass real email delivery entirely and accept a fixed, known verification code. How Clerk Test Credentials Work</a></h3> Any email address in the format: [name]+clerk_test@example.com</code></pre> …is recognized by Clerk as a test address. When this address triggers an email verification, Clerk skips sending a real email and instead accepts 424242</code> as the OTP code every single time. This works in your development and staging environments where you are using a Clerk test API key (sk_test_...</code> / pk_test_...</code>). It does not work in production. So your test credentials look like this: Email: testsprite+clerk_test@example.com Password: YourStrongPassword123! Verification code: 424242</code></pre> The name part (testsprite</code>) can be anything valid. The +clerk_test@example.com</code> suffix is what activates the special behavior. Step 1: Register the Test User in Your App</a></h3> Before your test suite runs, you need this user to exist in Clerk. You can either create them manually through your app’s sign-up flow once, or do it programmatically in your global setup: // testsprite.setup.ts import { createClerkClient } from "@clerk/backend"; const clerk = createClerkClient({ secretKey: process.env.CLERK_SECRET_KEY!, }); export async function setup() { const testEmail = "testsprite+clerk_test@example.com"; const testPassword = process.env.CLERK_TEST_PASSWORD!; // Check if the test user already exists const { data: existing } = await clerk.users.getUserList({ emailAddress: [testEmail], }); if (existing.length === 0) { await clerk.users.createUser({ emailAddress: [testEmail], password: testPassword, firstName: "Test", lastName: "User", }); console.log("✅ Test user created"); } else { console.log("✅ Test user already exists"); } }</code></pre> Add the password to your .env.local</code>: CLERK_TEST_PASSWORD=YourStrongPassword123!</code></pre>Step 2: Configure Testsprite with the Test Credentials</a></h3> Pass the test credentials to Testsprite so it knows what to type into the sign-in form: // testsprite.config.ts import { defineConfig } from "testsprite"; export default defineConfig({ globalSetup: "./testsprite.setup.ts", baseURL: "http://localhost:3000", auth: { email: "testsprite+clerk_test@example.com", password: process.env.CLERK_TEST_PASSWORD, otpCode: "424242", }, });</code></pre>Step 3: What Happens During Sign-In</a></h3> With these credentials in place, here is what the frontend test flow looks like: Testsprite opens your app in a browser and navigates to the sign-in page</li> It fills in testsprite+clerk_test@example.com</code> and your test password</li> Clerk prompts for the verification code</li> Testsprite enters 424242</code></li> Clerk accepts it and creates a real authenticated session</li> The browser is now logged in and Testsprite can navigate to any protected page</li> </ol> From here, all your frontend tests run against a fully authenticated session — the same way a real user would experience your app. Why 424242</code> Always Works</a></h3> Clerk’s test email format is a convention baked into their SDK. When Clerk sees a +clerk_test@example.com</code> address during a test-mode session, it short-circuits the email delivery system and registers 424242</code> as the valid OTP for that request. No email is sent. No inbox to check. The code is always the same and always valid. This is analogous to how Stripe uses 4242 4242 4242 4242</code> as a test card number — a fixed, well-known value that the system recognizes as being in test mode and treats accordingly. The Full Picture</a></h2> Once both fixes are in place, your test suite looks like this: Test type</th> Auth mechanism</th> What Clerk sees</th></tr></thead> Backend API tests</td> Bearer JWT from Backend SDK</td> Real session token, full auth()</code> context</td></tr> Frontend E2E tests</td> Sign-in via +clerk_test</code> email + 424242</code> OTP</td> Real browser session, full UI context</td></tr> </tbody></table> Neither approach involves bypassing auth, mocking Clerk, or special-casing your middleware. Both test the real code path. After setting this up across LucidHire’s test suite, every test that was previously blocked by auth started running cleanly. The backend tests hit real route handlers with real session data. The frontend tests navigated through the actual sign-in UI and landed on authenticated pages. Here is the same dashboard after the fix — the wall of Blocked results replaced almost entirely by green Pass: That is exactly what a good test suite should do. Your "Server Component" Is Running on the Client (And You Have No Idea) Jameel Ahmad — Tue, 14 Apr 2026 01:00:00 +0500 You write a component. No "use client"</code> directive. You fetch data directly, maybe even do a console.log</code> to confirm it’s running server-side. The log shows up — in your browser console. That’s the moment. The “wait, what?” moment. Next.js App Router made Server Components the default, which is great. But that default comes with a catch: it’s surprisingly easy to write code you think is server-only but is actually being executed on the client. Here are the real cases where this happens. Table of contents</a></h2> Case 1: No “use client” Doesn’t Mean Server Component</a></h2> The misconception: A component will render on the server simply because you didn’t add "use client"</code> to the top of the file. The reality: If you import and nest that component inside a parent that is a Client Component, it automatically inherits client behavior and runs in the browser. // UserProfile.tsx — no "use client", so it must be a Server Component, right? export default function UserProfile() { return <div>{/* sensitive render logic */}</div>; } // Sidebar.tsx "use client"; import UserProfile from "./UserProfile"; // ← now a Client Component export default function Sidebar() { const [open, setOpen] = useState(false); return ( <div> <UserProfile /> {/* running in the browser */} </div> ); }</code></pre> UserProfile</code> had no directive, but because it’s imported inside a Client Component, it gets bundled into the client and runs there. Any server-only logic inside it — DB calls, secret env vars — silently breaks or gets exposed. The fix: Pass the Server Component as children</code> instead of importing it directly. // page.tsx (Server Component) import Sidebar from "./Sidebar"; import UserProfile from "./UserProfile"; export default function Page() { return ( <Sidebar> <UserProfile /> {/* still a Server Component */} </Sidebar> ); } // Sidebar.tsx "use client"; export default function Sidebar({ children }) { const [open, setOpen] = useState(false); return <div>{children}</div>; }</code></pre> Components passed as children</code> or props are not pulled into the client boundary. They stay on the server. Case 2: Placing “use client” Too High in the Tree</a></h2> The misconception: You put "use client"</code> high up in your layout or page, assuming child components beneath it stay as Server Components since that’s the Next.js default. The reality: The directive at the top of the tree creates a boundary that forces the entire subtree beneath it to be bundled and executed on the client, completely wiping out Server Component benefits for every child. // app/layout.tsx "use client"; // ← placed here to use a single useState export default function RootLayout({ children }) { const [theme, setTheme] = useState("light"); return ( <html> <body> {/* Every single component rendered here is now a Client Component */} {children} </body> </html> ); }</code></pre> Every page, every data-fetching component, every child that should be running on the server — is now running in the browser. You’ve opted your entire app out of Server Components with one misplaced directive. The fix: Push "use client"</code> as deep as possible. If you only need interactivity for a theme toggle button, extract just that button into its own file and mark that file as "use client"</code>. // components/ThemeToggle.tsx "use client"; export default function ThemeToggle() { const [theme, setTheme] = useState("light"); return ( <button onClick={() => setTheme(t => t === "light" ? "dark" : "light")}> Toggle </button> ); } // app/layout.tsx — no "use client" needed here import ThemeToggle from "@/components/ThemeToggle"; export default function RootLayout({ children }) { return ( <html> <body> <ThemeToggle /> {/* only this is a Client Component */} {children} {/* everything else stays on the server */} </body> </html> ); }</code></pre>Case 3: Not Separating Client and Server Utils</a></h2> The misconception: You write utility functions for backend tasks — database queries, secret lookups — and assume they’ll safely stay on the server. The reality: If you accidentally import one of those server utilities into a client component, Next.js bundles that sensitive logic and ships it directly to the user’s browser. // lib/utils.ts — one file for everything export function formatDate(date: Date) { /* safe, UI logic */ } export async function getUserFromDb(id: string) { /* db query, secret logic */ } // components/ProfileCard.tsx "use client"; import { formatDate, getUserFromDb } from "@/lib/utils"; // ↑ getUserFromDb is now in the browser bundle</code></pre> You only meant to import formatDate</code>. But because both functions live in the same file, the entire module gets bundled — including your database logic. The fix: Separate your utilities by environment. Keep server-only logic in dedicated files and protect them with the server-only</code> package. // lib/server/db.ts import "server-only"; // ← hard build error if this gets imported client-side export async function getUserFromDb(id: string) { /* safe */ } // lib/utils.ts — only safe, UI-level helpers export function formatDate(date: Date) { /* fine anywhere */ }</code></pre> Now if lib/server/db.ts</code> ever ends up in a client bundle, Next.js throws a build error instead of silently shipping your DB logic to users. Case 4: Leaking Sensitive Data Through Props</a></h2> The misconception: You securely fetch data inside a Server Component and assume it stays secure because the fetch happened on the server. The reality: If you pass that sensitive data — tokens, passwords, hidden IDs, internal pricing — down as a prop to a Client Component, it gets serialized and sent to the browser. The user can read it in full. // app/dashboard/page.tsx (Server Component) export default async function DashboardPage() { const user = await db.query(`SELECT * FROM users WHERE id = ?`, [userId]); // user contains: { id, name, email, passwordHash, stripeSecretKey, internalScore } return <UserCard user={user} />; // ← passing the entire object down } // components/UserCard.tsx "use client"; export default function UserCard({ user }) { // user.passwordHash and user.stripeSecretKey are now in the browser return <div>{user.name}</div>; }</code></pre> You’re only displaying user.name</code>, but the entire object was serialized into the HTML payload and shipped to the client. Anyone can inspect the network response and read the rest. The fix: Pass only what the Client Component actually needs to render. // app/dashboard/page.tsx export default async function DashboardPage() { const user = await db.query(`SELECT * FROM users WHERE id = ?`, [userId]); return <UserCard name={user.name} email={user.email} />; // ← only safe fields }</code></pre> Never pass a raw database object to a Client Component. Treat the prop boundary the same way you’d treat an API response — intentionally shape what leaves the server. Edge Case: Server Actions Aren’t Private Functions</a></h2> Server Actions do execute on the server, so this section is a bit different — your code does run server-side. But there’s a fundamental misunderstanding about what that means for security. Adding “use server” Doesn’t Make a Function Private</a></h3> The misconception: You add "use server"</code> to a function thinking it’s a strict rule to “run this private utility on the server” — an internal function the outside world can’t touch. The reality: "use server"</code> creates a public-facing POST endpoint. The client can invoke it at will. If you don’t validate and authorize inside the action itself, you’ve left a door wide open. // app/actions.ts "use server"; export async function deleteUser(userId: string) { // No auth check. No ownership check. await db.delete("users", { id: userId }); // ← anyone can call this }</code></pre> This action is reachable via a POST request from any client — your app, someone else’s browser tab, a curl command. The fact that it runs on your server doesn’t make it safe; it makes it a publicly accessible API that does destructive work. The fix: Treat every Server Action like a public API route. Verify authentication and authorization inside the action on every single call. "use server"; import { auth } from "@/lib/auth"; export async function deleteUser(userId: string) { const session = await auth(); if (!session) throw new Error("Unauthorized"); if (session.user.role !== "admin") throw new Error("Forbidden"); await db.delete("users", { id: userId }); }</code></pre> Never assume a Server Action is protected because it lives in your codebase. Assume every action is reachable by anyone and validate accordingly. The Mental Model That Actually Helps</a></h2> Stop thinking of Server vs. Client as a property of individual files. Think of it as two separate execution environments, and your code lives in whichever one its import chain puts it in. "use client"</code> doesn’t mark a component as client-only. It marks a boundary — the point where the server tree ends and the client bundle begins.</li> Everything imported inside a Client Component becomes client code, regardless of its own directives.</li> Everything passed as props or children keeps its original context.</li> Server Actions are public endpoints, not private functions.</li> </ul> Once that clicks, the mask reveal makes sense. Your “Server Component” was always the client. You just hadn’t pulled it off yet. How TestSprite Helped Me Find a Silent Polar Checkout Bug (and How I Fixed It) Jameel Ahmad — Sun, 12 Apr 2026 14:00:00 +0500 I have been building Lucid Hire, a Next.js recruiter dashboard with Clerk auth, Neon Postgres, and Polar for subscriptions. The billing page lets recruiters click Upgrade to Pro and navigate to Polar-hosted checkout. In manual testing I had tunneling and env quirks, so I leaned on TestSprite—an MCP-connected E2E runner—to exercise the full app through a real browser session. One case kept failing: TC013, “Billing page remains usable after returning from external checkout.” The report was blunt: hitting /api/billing/checkout?plan=pro</code> returned HTTP 500 with a generic browser error page—no JSON, no stack trace in the UI. This post is about how that failure was actually a gift: TestSprite reproduced a path I had not fully validated, and chasing it led to a concrete bug in how we integrated Polar—not “Polar is down,” but our route crashing before the SDK could even run. Table of contents</a></h2> What TestSprite reported</a></h2> TestSprite generates a frontend test plan, runs Playwright-style flows against my local app (via a tunnel), and writes a report under testsprite_tests/tmp/raw_report.md</code>. For TC013, the relevant excerpt looked like this in spirit: The automation navigated to /api/billing/checkout?plan=pro</code> (same as our real Upgrade button).</li> The browser showed “This page isn’t working” / HTTP ERROR 500.</li> No redirect to Polar, so the test correctly marked a failure.</li> </ul> That told me the bug was server-side in our checkout API route, not a flaky click in the billing UI. Following the trail to src/app/api/billing/checkout/route.ts</code></a></h2> Our billing client triggers checkout with a full-page navigation—simple and intentional: const startUpgrade = (plan: "pro" | "max") => { setLoadingPlan(plan); window.location.href = `/api/billing/checkout?plan=${plan}`; };</code></pre> So every upgrade goes through GET /api/billing/checkout</code>. I opened the route handler next. Originally, the route used Checkout</code> from @polar-sh/nextjs</code>, which wraps @polar-sh/sdk</code> and builds a checkout session from query parameters. On the surface that is the “official” integration. The problem was what happened before Polar’s API was called. The mystery of the blank 500</a></h2> Inside @polar-sh/nextjs</code>, the checkout handler does something like this (simplified from the published package): const success = successUrl ? new URL(successUrl) : void 0; if (success && includeCheckoutId) { success.searchParams.set("checkoutId", "{CHECKOUT_ID}"); } try { const result = await polar.checkouts.create({ /* ... */ }); return NextResponse.redirect(redirectUrl.toString()); } catch (error) { console.error(error); return NextResponse.error(); }</code></pre> Two important details: new URL(successUrl)</code> runs outside the try</code> block. In JavaScript, new URL("/dashboard/settings/billing")</code> throws—relative URLs are invalid without a base. So if POLAR_SUCCESS_URL</code> was unset in a way that still led to bad input, or was documented as a “path only” value, the handler could throw before try</code> → Next.js responds with an unhelpful 500 and no JSON body. </li> When the Polar API failed, the helper returned NextResponse.error()</code>. That is also an opaque 500 from the browser’s point of view. TestSprite (and users) only see “something broke.” </li> </ol> Separately, our README listed POLAR_ACCESS_TOKEN</code> and product IDs but never POLAR_SUCCESS_URL</code>. Locally I had been “fine” until the exact combination of tunnel + env + navigation reproduced the crash in CI-style E2E. How TestSprite helped beyond “checkout is broken”</a></h2> Without TestSprite, I might have assumed: “Polar credentials are wrong,” or</li> “Test user is not allowed to checkout,” or</li> “Clerk session is missing.”</li> </ul> The report narrowed it: authenticated flows passed (billing page, plan copy, other cases), but the API route itself returned 500 when used like a real user (full navigation to the API URL). That pushed me to read the route + Polar adapter, not redo Clerk for the tenth time. So the value was not only automation—it was a reproducible, user-shaped repro attached to logs and video links in the TestSprite dashboard. The fix: own the checkout flow and make URLs safe</a></h2> I stopped delegating to @polar-sh/nextjs</code>’s Checkout()</code> for this route and called polar.checkouts.create()</code> from @polar-sh/sdk</code> directly, with: A resolver that always produces a valid absolute success URL</li> A try/catch</code> that returns JSON with a real error message (HTTP 502) when Polar rejects the request</li> </ol> 1. Resolve POLAR_SUCCESS_URL</code> safely</a></h3> Polar needs an absolute success URL. If the env var is missing, we default to returning the user to billing. If it is a relative path, we resolve it against NEXT_PUBLIC_APP_URL</code>, VERCEL_URL</code>, or the incoming request origin: function resolveCheckoutSuccessUrl(request: NextRequest): URL { const raw = process.env.POLAR_SUCCESS_URL?.trim(); const origin = process.env.NEXT_PUBLIC_APP_URL?.replace(/\/$/, "") || (process.env.VERCEL_URL ? `https://${process.env.VERCEL_URL}` : null) || request.nextUrl.origin; if (!raw) { return new URL("/dashboard/settings/billing", origin); } try { return new URL(raw); } catch { const path = raw.startsWith("/") ? raw : `/${raw}`; return new URL(path, origin); } }</code></pre> Then we append Polar’s checkoutId={CHECKOUT_ID}</code> placeholder the same way the official helper does: const successUrl = resolveCheckoutSuccessUrl(request); successUrl.searchParams.set("checkoutId", "{CHECKOUT_ID}");</code></pre>2. Create the session and redirect—or return a clear error</a></h3> const polar = new Polar({ accessToken, server: polarServerFromEnv(), }); try { const result = await polar.checkouts.create({ products: [productId], successUrl: decodeURI(successUrl.toString()), externalCustomerId: organization.id, customerEmail: appUser.email, customerName: appUser.name ?? undefined, metadata: { orgId: organization.id }, }); return NextResponse.redirect(result.url); } catch (error) { console.error("[billing/checkout] Polar API error:", error); return NextResponse.json( { error: checkoutErrorMessage(error) }, { status: 502 }, ); }</code></pre> After this change: Misconfiguration (wrong token, wrong sandbox vs production product id) still fails—but the response is JSON with a message, and the server log has the Polar error. TestSprite (or curl) can surface that instead of a blank chrome error page.</li> Missing or relative POLAR_SUCCESS_URL</code> no longer crashes the process on new URL()</code>.</li> </ul> What I learned</a></h2> E2E tools like TestSprite are not only for “click happy paths.” They excel at boring but exact repros: same URL, same query string, same navigation semantics as production.</li> Third-party adapters (@polar-sh/nextjs</code>) save time until they hide thrown errors or parse env in ways that assume perfect configuration. Sometimes owning the ten lines of SDK calls buys you observability and control.</li> POLAR_SUCCESS_URL</code> should be documented next to tokens and product IDs: absolute URL preferred; if you use a path, we now resolve it—but you should still set NEXT_PUBLIC_APP_URL</code> (or rely on request.nextUrl.origin</code> in dev) so the base is correct behind proxies and tunnels.</li> </ul> Fixing "No Wi-Fi Adapter Found" on Fedora with Intel AX201 Jameel Ahmad — Wed, 25 Feb 2026 20:10:00 +0500 I was working on my Lenovo ThinkPad X13 Yoga Gen 2 running Fedora Linux 43 when suddenly the Wi-Fi disappeared. The settings showed a dreaded message: “No Wi-Fi Adapter Found”. What made it even more frustrating was that the hardware was clearly there—I had an Intel Wi-Fi 6 AX201 card installed. After some investigation, I discovered this was a common issue with Intel AX201 wireless cards on Linux, particularly affecting Fedora users. The driver would work sometimes but fail to initialize properly on boot. Table of contents</a></h2> Diagnosing the Problem</a></h2> First, I needed to understand what was actually happening. I ran some diagnostic commands to check if the hardware was detected: lspci -nnk | grep -iA3 network</code></pre> Output showed my card was detected: 00:14.3 Network controller [0280]: Intel Corporation Wi-Fi 6 AX201 [8086:a0f0] (rev 20) Subsystem: Intel Corporation Device [8086:0070] Kernel modules: iwlwifi</code></pre> The hardware was there, and the iwlwifi</code> driver module was available. So what was the issue? The Real Culprit: Driver Initialization Timeout</a></h2> I checked the kernel messages to see what was happening during boot: sudo dmesg | grep -i iwl</code></pre> Buried in the output was the critical error: iwlwifi 0000:00:14.3: probe with driver iwlwifi failed with error -110</code></pre> Error -110 is a timeout error. The driver was trying to communicate with the Wi-Fi card but couldn’t establish a connection within the expected time frame. This is a well-known issue with Intel AX201 cards on Linux systems. I also verified that the driver module was loaded: lsmod | grep -i iwl # Output: iwlwifi 589824 0 cfg80211 1544192 1 iwlwifi</code></pre> The module was loaded, but it just couldn’t talk to the hardware properly. The Temporary Solution That Revealed the Root Cause</a></h2> At first, I tried reinstalling the firmware: sudo dnf reinstall iwl*-firmware sudo reboot</code></pre> This worked! After the reboot, Wi-Fi appeared and connected successfully. But when I rebooted again, the problem came back. The Wi-Fi would disappear on every other boot. This intermittent behavior told me something important: the firmware and driver could work, but they weren’t being initialized properly during the boot process. The Permanent Fix: A Multi-Layered Approach</a></h2> After researching and testing, I found that a combination of solutions was needed to make the Wi-Fi work reliably across all reboots. 1. Reinstall the Firmware</a></h3> First, ensure the Intel wireless firmware is properly installed: sudo dnf reinstall iwl*-firmware</code></pre>2. Add the Driver to Initramfs</a></h3> The initramfs (initial RAM filesystem) is loaded early in the boot process. By adding the iwlwifi driver to it, we ensure it’s available when the system needs it: echo 'add_drivers+=" iwlwifi "' | sudo tee /etc/dracut.conf.d/iwlwifi.conf sudo dracut -f --regenerate-all</code></pre>3. Disable Power Management</a></h3> The timeout error often occurs because aggressive power management prevents the driver from initializing properly. Disabling power saving for the Wi-Fi module fixes this: echo "options iwlwifi power_save=0" | sudo tee /etc/modprobe.d/iwlwifi.conf</code></pre>4. Rebuild Initramfs Again</a></h3> After adding the power management configuration, rebuild the initramfs to include these settings: sudo dracut -f --regenerate-all</code></pre>5. Create a Systemd Service as a Backup</a></h3> As an extra layer of reliability, I created a systemd service that forces the driver to reload on every boot: sudo tee /etc/systemd/system/iwlwifi-reload.service << 'EOF' [Unit] Description=Reload iwlwifi module After=network-pre.target Before=network.target [Service] Type=oneshot ExecStart=/usr/sbin/modprobe -r iwlwifi ExecStart=/usr/sbin/modprobe iwlwifi RemainAfterExit=yes [Install] WantedBy=multi-user.target EOF sudo systemctl enable iwlwifi-reload.service</code></pre>6. Final Reboot</a></h3> sudo reboot</code></pre>Why This Combination Works</a></h2> This multi-layered approach ensures Wi-Fi reliability through: Firmware reinstallation: Ensures the latest Intel AX201 firmware is available</li> Initramfs configuration: Makes the driver available early in the boot process</li> Power management disabled: Prevents timeout errors during initialization</li> Systemd service: Provides a safety net by forcing module reload if other methods fail</li> </ul> The combination handles edge cases across kernel updates, firmware updates, and various boot scenarios. Verification</a></h2> After rebooting, you can verify everything is working: # Check if the service is active systemctl status iwlwifi-reload.service # Check if power_save is disabled cat /etc/modprobe.d/iwlwifi.conf # Verify Wi-Fi adapter is detected nmcli device status</code></pre>Conclusion</a></h2> The Intel Wi-Fi 6 AX201 is an excellent wireless card, but its Linux drivers can be finicky on Fedora. The error -110 timeout issue is frustrating because it’s intermittent—sometimes working, sometimes not. By combining proper initramfs configuration, power management tweaks, and a systemd service fallback, I’ve achieved reliable Wi-Fi functionality across all reboots. This solution should persist across system updates and kernel changes. If you’re experiencing similar issues with Intel wireless cards on Fedora or other Linux distributions, this comprehensive approach should help you achieve stable Wi-Fi connectivity. Overcoming YouTube Authentication Hurdles with yt-dlp Jameel Ahmad — Fri, 30 Jan 2026 03:02:00 +0500 For anyone who loves managing their own media library, yt-dlp is the gold standard. It is an incredibly powerful command-line tool that can download video and audio from thousands of sites with surgical precision. Whether you want a specific resolution or just a high-quality MP3, yt-dlp handles it with ease. However, as platforms like YouTube tighten their security to prevent botting, we often run into “Sign in to confirm you’re not a bot” errors or age-restriction blocks. While yt-dlp has a built-in feature to grab cookies directly from your browser, modern security updates have made this process surprisingly frustrating. Table of contents</a></h2> The “Database Locked” Headache</a></h2> Usually, you would try to use your browser’s session by adding --cookies-from-browser edge</code> to your command. But more often than not, you’ll be greeted by this annoying error: Extracting cookies from edge ERROR: Could not copy Chrome cookie database. See [https://github.com/yt-dlp/yt-dlp/issues/7271](https://github.com/yt-dlp/yt-dlp/issues/7271) for more info </code></pre> This happens because Chromium-based browsers (like Edge, Chrome, and Brave) lock their cookie database file while the browser is open. Even if you close the window, background processes often keep the file “in use,” preventing yt-dlp from reading your login session. The Solution: Manual Cookie Extraction</a></h2> The most reliable way to bypass this without constantly closing your browser is to use a cookie export extension. This gives yt-dlp a static “snapshot” of your login session that it can read freely. 1. Install the Extension</a></h3> I use an extension called “Get cookies.txt LOCALLY”. It’s lightweight and doesn’t send your data to any external servers. Install it from the Chrome/Edge Web Store.</li> Open YouTube and make sure you are logged in.</li> Click the extension icon and export your cookies as a .txt</code> file.</li> </ul> 2. Prepare Your Folder</a></h3> Save the file (e.g., cookies.txt</code>) directly into the folder where you run your commands. In my case, that is C:\Users\jameel\music</code>. 3. Run the Correct Command</a></h3> Now, instead of telling yt-dlp to look into the browser, we point it directly to our text file using the --cookies</code> flag: yt-dlp --js-runtimes node --remote-components ejs:github --cookies cookies.txt -x --audio-format mp3 --audio-quality 0 "media_link_to_be_download" </code></pre>Why This Works Better</a></h3> No Conflicts: It doesn’t matter if Edge is open, closed, or running 50 tabs; the text file is always accessible.</li> Consistency: This method works even when browser updates change how internal databases are encrypted.</li> Bypass Captchas: Since the file contains your actual “logged-in” session, YouTube treats the request as coming from a verified user.</li> </ul> A Note on Security</a></h2> Your cookies.txt</code> file is essentially a temporary key to your account. Never share this file with anyone else! Once you are done with your downloads, it is a good habit to delete the text file or move it to a secure location. How I Fixed Missing H.264 Codecs on a Fresh Fedora Install Jameel Ahmad — Fri, 09 Jan 2026 01:43:00 +0500 I freshly installed Fedora Linux Workstation 43 on my PC and tried to play a video. The video played, but it was blank. It turned out there was an issue with the missing video decoder required to run this video: H.264. The issue is that this encoder is proprietary and does not come with Fedora by default due to licensing restrictions. To fix this, I had to dive into the world of FFmpeg and package management. Table of contents</a></h2> The Mystery of the “Missing” FFmpeg</a></h2> There is a huge library of multimedia encoders and decoders out there called FFmpeg. I needed to check if FFmpeg was installed in Fedora and if it included the H.264 encoder. I used the command: dnf list installed | grep ffmpeg </code></pre> Surprisingly, I got nothing. However, when I ran ffmpeg</code> directly in the terminal, the command worked! It was strange to me how a command-line utility could be available even when it didn’t appear as “installed” in my package list. Finding the Culprit: ffmpeg-free</a></h2> It turns out Fedora comes with a “free” version of FFmpeg that excludes proprietary encoders. To solve the mystery, I first checked where the command was running from: which ffmpeg # Output: /usr/bin/ffmpeg </code></pre> Then, I passed this path to RPM to check which package exactly owned this file: rpm -qf /usr/bin/ffmpeg </code></pre> The result: ffmpeg-free-7.1.2-2.fc43.x86_64</code>. This confirmed that the “free” version was installed, which lacks the H.264 proprietary encoder. The Solution: Swapping to RPM Fusion</a></h2> To fix this, I needed to enable the RPM Fusion repositories and swap the limited version for the full one. 1. Enable Repositories</a></h3> First, I enabled the free and non-free RPM Fusion repositories: sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm </code></pre>2. Swap the Packages</a></h3> Then, I used this command to install the proprietary version of FFmpeg and remove the pre-installed free one: sudo dnf swap ffmpeg-free ffmpeg --allowerasing </code></pre>Fixing Lag and Crashes</a></h2> The codec was installed successfully and the video played, but I hit another problem: the video was lagging heavily and the player sometimes crashed. The default video player tries to find the right codec automatically, but sometimes it tries to roll back to the “free” version or struggles with dependencies. To enforce all multimedia apps to use the preferred encoding packages, I ran: sudo dnf update @multimedia --setopt="install_weak_deps=False" --exclude=PackageKit-gstreamer-plugin </code></pre>What does this command do?</a></h3> @multimedia</code>: This is the group in which all multimedia-related apps are grouped by Fedora.</li> install_weak_deps=False</code>: This prevents the system from pulling back in the limited “free” versions as optional dependencies.</li> --exclude=PackageKit-gstreamer-plugin</code>: This stops the GUI software store from interfering with our manual codec setup.</li> </ul> After running this, the H.264 videos played perfectly smooth!

Jameel Ahmad

Record any Privacy Protected Screen like Snapchat, Netflix and other Social & OTT Platforms

What You’ll Need</a></h2> A Fedora Linux machine (I used Fedora 43 Workstation)</li> GNOME Boxes (a virtualization tool)</li> OBS Studio (free and excellent screen recorder)</li>

2. Create an Isolated Virtual Machine</a></h3> Open GNOME Boxes</strong>.</li> Click Create a new virtual machine</strong>.</li> Choose the latest Fedora Workstation ISO (or let Boxes download it for you).</li> Give the VM 4 GB RAM and 4 CPU cores (plenty for Snapchat or Netflix).</li>

How I Fixed Testsprite Tests Getting Blocked by Clerk Auth in Next.js

Your "Server Component" Is Running on the Client (And You Have No Idea)

How TestSprite Helped Me Find a Silent Polar Checkout Bug (and How I Fixed It)

How TestSprite helped beyond “checkout is broken”</a></h2> Without TestSprite, I might have assumed:</p> “Polar credentials are wrong,” or</li> “Test user is not allowed to checkout,” or</li>

Fixing "No Wi-Fi Adapter Found" on Fedora with Intel AX201

Overcoming YouTube Authentication Hurdles with yt-dlp

Why This Works Better</a></h3> No Conflicts:</strong> It doesn’t matter if Edge is open, closed, or running 50 tabs; the text file is always accessible.</li> Consistency:</strong> This method works even when browser updates change how internal databases are encrypted.</li>

How I Fixed Missing H.264 Codecs on a Fresh Fedora Install