Coder Legion - Recent posts tagged debugging

The Semicolon That Stole 5 Days of My Life

Sat, 31 Oct 2026 08:21:59 +0000

I have never been this frustrated with a single bug in my life.

And the culprit? The classic, infamous semicolon.

I recently started exploring Express.js and wired up a MongoDB database for an assignment. Connecting the database was a small hurdle, but that wasn’t the real fight.
The terminal said the database was connected. But Postman and the browser? Total silence. No response, no error.

I created a fresh test database. Nothing. Then I disconnected the database entirely and bypassed my .env file, and suddenly the routes worked.

So my brain locked onto the wrong villain: “The URI must be broken.” “Maybe it’s the network whitelist.” “Maybe the connection string is formatted wrong.”

I spent 5 days down that rabbit hole.

This morning, with the submission deadline today, I told myself: if I don’t fix this now, I’m deleting the whole folder and starting over. So I opened every file one last time.
And there it was, hiding in plain sight in my .env file:

PORT=3000;

In JavaScript, a semicolon ends a statement. In a .env file, it’s just part of the value. My port wasn’t 3000, it was “3000;”, so the server never listened where I was sending requests.

Five days. One character.

I still can’t decide whether to be relieved that it works or annoyed that a single semicolon stole my peace for a week. But this is part of what we signed up for as developers. The wins are great, and the silent syntax traps are real.

No time to celebrate though. The deadline is today.

What’s the most ridiculous bug that ate days of your life for no good reason? I want to hear your horror stories.

Adiós.

WordPress Crash Recovery & Plugin Conflict Resolution

Fri, 30 Oct 2026 14:36:25 +0000

When a WordPress site crashes immediately after an update, the immediate business impact is lost revenue, disrupted customer workflows, and compromised search standing. In production environments, standard advice like "restore a backup from yesterday" can cause critical data loss: orders placed between the backup and the crash, customer registrations, and recent transactions vanish.

A disciplined engineering approach treats a crashed WordPress site as a contained system failure: isolate the execution failure, restore availability, fix the root cause, and verify data integrity before returning traffic to normal operations.

Common Crash Failure Modes After Updates

WordPress crashes after updates typically stem from four discrete architectural failure modes:

PHP Fatal Errors (Type Errors & Deprecations): A plugin update requires PHP 8.1+ syntax or library extensions that conflict with the server runtime or an older theme calling deprecated functions.
Hook and Filter Signature Conflicts: Two active plugins hook into the same action (e.g., woocommerce_checkout_order_processed or template_redirect) expecting incompatible argument types or returning invalid objects.
Database Schema Migrations & Locked Tables: Complex plugins (WooCommerce, membership tools, custom post-type managers) execute DDL migrations upon activation. If a migration times out or hits MySQL lock contention, queries fail across the application.
Autoloaded Options & Memory Exhaustion: Plugins accumulating transient data in wp_options with autoload = 'yes' spike PHP memory usage beyond memory_limit, triggering fatal out-of-memory crashes on high-concurrency requests.

Systematic Diagnostic Protocol

When diagnosing a crashed WordPress production instance, follow this 5-step engineering triage:

Step 1: Capture Raw Error Logs Without Exposing Stack Traces

Do not enable WP_DEBUG_DISPLAY on a live production URL. Instead, enable debug logging to a private log destination:

// In wp-config.php (before /* That's all, stop editing! */)
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/var/log/wordpress/debug.log'); // Secure path outside public web root
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', '0');

Inspect debug.log or the web server error log (NGINX/Apache/FPM error log) to identify the exact file, line number, and exception stack trace.

Step 2: Safe Plugin Isolation via WP-CLI

Avoid renaming the entire wp-content/plugins folder if possible, as this deactivates all plugins and breaks widget and database mappings upon reactivation. Use WP-CLI to isolate the culprit:

# Check status of installed plugins
wp plugin list --status=active

# Deactivate the suspect plugin identified in the error stack trace
wp plugin deactivate offending-plugin-slug --skip-plugins --skip-themes

# Verify frontend HTTP response code
curl -I https://example.com

Step 3: Check MySQL Database Integrity and Migration Locks

If the error indicates missing tables or broken queries, verify table health:

# Check and repair WordPress core and plugin tables
wp db check
wp db repair

# Identify oversized autoloaded options causing memory exhaustion
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 10;"

Step 4: Patch Compatibility or Pin Version

If the site requires the updated plugin for business operations, evaluate whether a targeted patch (e.g., handling a null object check in a template hook) or a clean version downgrade via WP-CLI is appropriate:

# Safely roll back to previous known-stable version
wp plugin install offending-plugin-slug --version=2.4.1 --force

Step 5: Verification and Regression Testing

Verify that critical customer journeys work end-to-end:

Homepage, archive, and single post rendering
User authentication and session persistence
E-commerce cart, checkout, and webhook callbacks
Scheduled cron tasks (wp cron event list)

When to Seek Engineering Assistance

If a WordPress crash involves corrupted database transactions, custom plugin architecture conflicts, security compromises, or legacy codebase friction, contained engineering intervention restores stability safely.

For rapid assistance with an active failure or production regression, see WordPress & website bug fixing or queue an urgent bug fix. To prevent update regressions entirely with weekly staging tests and daily backups, explore the WordPress Care Plan. If your platform requires broader architecture stabilization, review SazM's Diagnostic Audits or start a direct technical inquiry at the contact page.

Originally published with full diagnostic protocols at SazM: WordPress Crash Recovery & Plugin Conflict Resolution.

I Solved the Same Gmail Problem Two Ways Without Noticing

Thu, 29 Oct 2026 13:52:12 +0000

This is the third post from my n8n intake classifier, a practice project for a fictional automation agency that I built with an AI collaborator. The first was about the classification prompt. The second was about ambiguous, invalid and system_error. This one is about the wiring after classification: where logging goes, what the Gmail node does to your data, and a bug I only found by opening real inboxes. The workflow is in the GitHub repository.

A quick orientation: n8n is a workflow automation tool, and a workflow is built from nodes, each one a single step. The ones that matter here are Switch (sends an item down one of several paths), Set (reshapes the data) and Gmail (sends an email).

Where logging was supposed to go

After classification, a Switch node sends each submission down one of five paths, and each path sends emails. Every submission also gets logged to Google Sheets. For this phase I planned to work the way I had in the earlier ones: Sheets first, then emails, one branch at a time.

Before building anything, I caught a conflict. Logging is the same logic on all five paths, and only the data changes. Putting it first inside each branch meant five copies of one node, or converging after Sheets and then branching again to send category-specific emails. Neither made sense. So I flipped the order: build the emails first, since those differ per category, and let all five paths converge on one shared Sheets node at the end.

Gmail replaces your data

The first branch I built showed a second problem. When the Gmail node sends an email, the item it passes on is Gmail's own send confirmation, not the submission. Name, Email and description were gone by the time anything downstream needed them. The LLM Chain node had done the same thing to me earlier.

In the ambiguous/system_error branch, I added a Set node right after the internal notification to rebuild one clean object. The IF node and both client emails read from that, instead of each reaching back to whichever earlier node had the data. In simple_automation, I added a Set node after the client email to rebuild the object before it reached the shared Sheets node.

Noticing I'd solved it twice

While wiring the final Sheets node, I looked at the ambiguous/system_error branch and saw it fed Sheets from two points off the same rebuild node, one path through the client emails and one straight to Sheets. That wasn't a bug. The email path never reconnected to Sheets, so nothing was logged twice. But it showed me I had solved the Gmail problem two different ways. Everywhere else I rebuilt the data after the email. In this branch I branched before the email, because Sheets never needed anything the email step produced.

Moving logging upstream

That comparison pointed at something bigger. Every branch converged on one Sheets node, so there was no reason logging should depend on any email succeeding. A Gmail send can fail for reasons that have nothing to do with the submission.

I moved the Sheets connection to the two points right after classification: one for a successful classification and one for the failure handler. Both now feed the Switch and Sheets in parallel. Two side effects followed. has_partial_intent only had to be added in two places instead of four, and I could delete the end-of-branch Set nodes that existed only to feed the old Sheets wiring.

Before deleting any of them, I checked each one. Some still fed a client email's own data, and removing one of those would have broken a client-facing email without touching Sheets. I kept those.

The final build still contains both patterns. The ambiguous/system_error branch has its rebuild node, and the other client emails reach back to earlier nodes by name:

={{ $('Route: By Classification Category').item.json.Email }}

I haven't compared whether one pattern is more robust than the other. What changed is that logging no longer depends on either.

Checking real inboxes

After the rewiring, I retested every branch individually and checked real inboxes, not just node output. That caught a bug in the ai_workflow branch: the internal notification and the client email had their destinations swapped. The internal-only message went to the client, and the client's confirmation went to the team.

Both emails sent without errors, so nothing had failed that would make me suspect a problem. Only who received what showed it. I then confirmed the simple_automation branch had no swap, since I'd used the same inbox check there.

My notes don't record how the swap got there, or whether the rewiring caused it, so I won't guess. The current build sends each internal email to the team address and each client email to the submitter.

A test case I wrote wrong

While testing ambiguous, my first case was a deliberately vague description. It came back as invalid, and I took that as a bug. Reading the reasoning showed the classifier was right. Vague wording alone doesn't give any category a specific signal to rest on, which is a different situation from two categories each being concretely supported. I wrote a sharper case with explicit signals for both ai_workflow and custom_integration, and that one returned ambiguous.

What this doesn't show

Every test used descriptions I wrote. A forced classification failure does produce a row in the sheet, with the has_partial_intent cell empty, because the model never produced a value on that path. I did not test what happens if the Sheets step itself fails.

What I take from it is narrow: logging shouldn't wait on anything that can fail for unrelated reasons, and a branch that sends emails isn't tested until I've read the emails.

PS4 Pro Belize DDR3 patch v2

Sat, 24 Oct 2026 08:36:00 +0000

The last time the DDR3 memory on PS4 pro has a critical problem it was capped under 11mb/s speed how much I tied I failed every time

then I notice something while debugging through the southbridge well it turns out DDR3 has it's own southbridge DMA engine but I don't really notice at first.

and after some more debugging it turns out my DDR3 chip (1 GB on the southbridge) was being read by the CPU personally, 8 bytes at a time, through a tiny PCI window ~10.6 MB/s. and that was the main bottleneck of all.

now it feels like I almost fix the issue but nope the southbridge DMA engine has no Linux driver for PS4 to use it.

and after more debugging it turns out Sony's PS4 gameOS aka orbis uses that chip (their sbram driver), but the code is closed.

So, I used AI to reverse engineer the kernel binary and everything started making sense now

the chip lives at 0xC0000000 + offset on the internal bus and everything moves through the southbridge DMA engine with exact protocol byte-count, source, dest, then the 0x1d40 "go" register, and write 0x11 to the interrupt-mask register.

after that it's time to do the main patch The implementation

On the ps4linux it sees the southbridge DMA engine as a pci device: 104d:90cd. The driver asks linux for it, switches it on, and maps its register memory. Now the engine can't touch program memory directly. everything goes through one special buffer the driver allocates at startup a small chunk of RAM that is always below 4 GB and always coherent (DMA-visible) think of it as the loading dock between the CPU and the DDR3.

After the patch bake into the kernel and the result

	old patch	new patch
reads	10.6 MB/s	504 MB/s
writes	~138 MB/s	425 MB/s
ceiling	unknown	~1.4 GB/s (65,408 B jobs @ 1,383 MB/s)

The engine itself moves data at up to ~1.4 GB/s. what used to be a 10.6 MB/s unusable brick is now a fast little swap chip on PS4linux

How to Fix Metro Bundler Stuck or Not Starting Errors in React Native

Thu, 22 Oct 2026 12:02:08 +0000

If you've worked with React Native for a while, you've probably run into a problem where Metro refuses to start, gets stuck while bundling, or leaves your app waiting for JavaScript that never arrives.

Sometimes the terminal shows an error immediately. Other times, Metro appears to start normally, but the app stays on a loading screen or fails to connect to the development server.

The frustrating part is that these symptoms can have completely different causes. A port conflict, stale cache, broken dependency installation, invalid configuration, or network issue can all look like a Metro problem.

Here's how to narrow it down and fix the actual cause instead of repeatedly restarting your project and hoping something changes.

1. Identify What Metro Is Actually Doing

Before changing anything, identify which of these situations matches your problem.

Metro won't start: The development server exits with an error, refuses to launch, or reports that a port is already in use.
Metro starts but gets stuck bundling: The terminal shows that bundling has started, but it never finishes.
The app cannot connect to Metro: The server appears to be running, but the application displays a loading screen or a connection error.
Metro starts, but the app crashes: Bundling may be successful, but a JavaScript exception or native configuration problem prevents the app from running.

These are different failure points. Clearing the cache might help with a stale bundle, but it won't fix a port occupied by another process or an invalid native configuration.

Start with the simplest checks and move toward more disruptive fixes only when necessary.

2. Stop Metro and Start It Again

First, stop any Metro server running in the terminal by pressing Ctrl + C.

Then start it using the command appropriate for your project.

If you're using Expo

From your project directory, run:

npx expo start

To clear Expo's Metro cache at the same time, use:

npx expo start --clear

If you're using React Native CLI

Start Metro from your project's root directory:

npx react-native start

If you suspect stale cached files, use:

npx react-native start --reset-cache

Important: You don't need to clear the cache every time Metro fails. Start with the normal command. Use the cache-reset option when the symptoms suggest stale or inconsistent cached data, or when a normal restart doesn't help.

If Metro exits immediately, read the terminal output before trying another command. The first meaningful error is often more useful than the final stack trace.

3. Check Whether Port 8081 Is Already in Use

Metro normally uses port 8081. If another process is listening on that port, Metro may fail to start or ask you to use a different one.

The terminal might show a message similar to:

Error: listen EADDRINUSE: address already in use :::8081

This means another process is already using the requested address and port.

On Windows

Open Command Prompt and run:

netstat -ano | findstr :8081

Look for a line containing LISTENING. The last column contains the process ID (PID).

You can identify the process with:

tasklist /FI "PID eq 12345"

Replace 12345 with the actual PID.

If you've confirmed that the process is an old Metro server you no longer need, you can stop it:

taskkill /PID 12345 /F

On macOS or Linux

Run:

lsof -i :8081

Inspect the process listed for port 8081. If it's an old Metro process that you no longer need, stop that specific process:

kill <PID>

Replace <PID> with the actual process ID.

Don't terminate a process simply because it's using the port. Confirm what it is first, especially if other development tools are running.

Once the port is available, start Metro again.

4. Clear Metro's Cache When Bundling Gets Stuck

Metro transforms your JavaScript files and their dependencies into a bundle the application can execute. Cached transformation results help make subsequent builds faster, but stale or inconsistent cached data can sometimes cause confusing behavior.

Typical symptoms include:

Bundling worked before, but now fails after code or dependency changes.
The app appears to use an older version of your JavaScript.
Metro repeatedly fails while transforming files without an obvious dependency error.
A normal restart doesn't resolve the problem.

Try the appropriate cache-reset command from Step 2.

After the cache is cleared, let Metro rebuild the bundle. The first build can take longer because the cached transformation results need to be regenerated.

If the same error returns, don't keep clearing the cache. Look at the specific file, dependency, or configuration mentioned in the terminal output. A repeatable error usually means there's something more specific to fix.

5. Check Your Dependencies Before Reinstalling Everything

Metro depends on the packages and configuration in your React Native project. If a package installation was interrupted, dependencies were changed, or incompatible versions were introduced, Metro may fail while loading its configuration or resolving modules.

Start by checking the actual error.

For example, these messages point toward different problems:

Cannot find module ...

Unable to resolve module ...

Cannot find module 'metro-config'

A missing module doesn't automatically mean the entire dependency installation is broken. It might be an incorrect import path, a package that was never installed, or a version mismatch.

Check the following:

Did the problem start immediately after installing, removing, or updating a package?
Does the error identify a particular module or package?
Does your project use the package versions expected by its React Native or Expo version?
Did you accidentally run the installation command from the wrong directory?

If the project uses npm and has a valid, committed package-lock.json, a clean installation may be appropriate:

npm ci

This reinstalls dependencies according to the lockfile and removes the existing node_modules directory as part of the process.

For a Yarn project, use the installation command appropriate for its Yarn version and existing lockfile. Don't switch package managers or delete your lockfile just to see whether Metro starts.

Avoid deleting node_modules, lockfiles, and caches all at once as your first response. Doing so can introduce new version differences and make it harder to identify what originally caused the failure.

6. Check Metro and Expo Configuration

If Metro reports an error while loading its configuration, clearing the cache or reinstalling dependencies might not help.

Look for changes to files such as:

metro.config.js
babel.config.js
package.json
Expo app configuration, such as app.json or app.config.js

Pay particular attention to recent changes involving custom Metro configuration, Babel plugins, aliases, monorepo settings, or package versions.

For example, if Metro fails while loading metro.config.js, inspect the configuration and the package named in the error. A missing import or incompatible configuration dependency can prevent the server from starting at all.

If the problem appeared after a configuration change, compare that change with the last working version. Reverting one recent change is often more informative than rebuilding the entire environment.

For Expo projects, also make sure you're following the configuration requirements for your installed Expo SDK rather than copying a Metro configuration from an unrelated project or older tutorial.

7. If Metro Runs but the App Cannot Connect

A running Metro server doesn't guarantee that your app can reach it.

This distinction matters because repeatedly resetting Metro's cache won't fix a connection problem.

Check the development-server URL

When Metro starts, inspect the URL or connection information it prints in the terminal.

If you're using a physical device, make sure the device and computer can communicate over the selected network. VPNs, firewalls, guest Wi-Fi networks, and network isolation can interfere with local development connections.

If you're using Expo

Expo supports different connection methods depending on your environment and configuration. If the normal connection method doesn't work, try the tunnel option:

npx expo start --tunnel

A tunnel can help when the device cannot reach your computer directly over the local network, although it may be slower and depends on the tunnel service being available.

If you're using an Android emulator

Check that the emulator is running and that the development server is reachable. For a React Native CLI workflow using the standard Android emulator setup, you can forward port 8081 with:

adb reverse tcp:8081 tcp:8081

This is useful when the emulator needs a route to Metro through Android Debug Bridge. It isn't a universal fix for every device or connection setup.

If the app can connect but crashes after loading the bundle, move on to the JavaScript or native error shown by the app. At that point, Metro itself might be working correctly.

8. Don't Confuse a JavaScript Error With a Metro Startup Failure

Sometimes developers blame Metro because the application stops working immediately after a successful bundle.

But these messages describe different problems:

Metro startup error: The development server cannot initialize.
Module resolution error: Metro cannot find or resolve a requested module.
JavaScript runtime exception: The bundle loads, but the application encounters an error while executing code.
Native build error: The Android or iOS application fails during native compilation or configuration.

For example, if Metro reports that it cannot resolve a module imported by App.tsx, investigate the import path, filename, package installation, and any configured aliases.

If the Android build fails before the application starts, inspect the native build output instead of treating every failure as a Metro cache problem.

Finding the correct failure point saves time because each category requires a different solution.

9. When None of These Fixes Works

If Metro still refuses to start, collect the evidence before making more changes.

A useful troubleshooting report should include:

The exact command used to start Metro.
The full terminal error, especially the first meaningful error before the stack trace.
Your operating system.
Whether the project uses Expo or React Native CLI.
The relevant React Native and Expo versions.
Any recent dependency or configuration changes.
Whether Metro fails to start, gets stuck bundling, or starts while the app cannot connect.

Remove access tokens, passwords, private URLs, and other sensitive information before sharing logs publicly.

If the output contains several errors, don't assume the final message is the root cause. A failure to load one configuration dependency can trigger multiple follow-up errors.

This is also where a diagnostic tool can help. If you've already tried the obvious fixes and the logs are difficult to interpret, you can paste the relevant error and technical context into FixMyError. It can help analyze the failure, identify likely causes, and suggest targeted next steps instead of making you cycle through unrelated fixes.

Final Thoughts

When Metro Bundler gets stuck or refuses to start, the best approach is to identify where the failure occurs before changing your project.

Start with a normal restart, check port 8081, clear the cache when appropriate, and inspect dependency or configuration errors when they appear. If Metro is running but the app cannot connect, troubleshoot the connection rather than repeatedly resetting the bundler.

The goal isn't to run every possible fix. It's to find the specific reason your development environment stopped working and make the smallest change that resolves it.

What part of debugging does AI still struggle with most?

Sun, 18 Oct 2026 05:56:14 +0000

AI can find patterns in logs faster.

The harder part is deciding which pattern actually matters.

Good debugging still needs context, judgment, and a clear question.

What part of debugging do you think AI still struggles with most?

Good debugging starts with better questions

Fri, 16 Oct 2026 03:27:21 +0000

When production breaks, the first question should not be: Who broke it?

A better starting point is:

"What changed in the system?"

That shifts the discussion toward evidence:

recent deployments
configuration changes
dependency behavior
traffic patterns
logs, metrics, and traces

For me, evidence-first debugging usually leads to faster diagnosis and better team behavior.

What question do you ask first when a production issue starts?

Why Does Code Work Locally but Fail in Production?

Wed, 14 Oct 2026 12:39:53 +0000

One of the most frustrating problems in software development is when everything works perfectly on your machine, but breaks after deployment. 💀

The tricky part? The code itself isn't always the problem.

Here are five things I would investigate first:

Environment variables
A missing API key, incorrect URL, or improperly configured environment variable can break an otherwise working application.
Dependency differences
Different package versions or runtime environments can produce unexpected behavior.
API and CORS configuration
An endpoint that works locally might fail in production because of origin restrictions, incorrect URLs, or deployment configuration.
Database permissions
A feature may work with local development permissions but fail when production security policies are enforced.
Build and deployment settings
Incorrect routes, missing assets, case-sensitive file paths, and build configuration differences can cause issues that never appeared locally.

My rule is simple: don't assume the deployment is broken until you've identified where the failure actually occurs.

Reproduce the issue, inspect the logs, isolate the failing layer, and test the fix before deploying again.

💬 Question for developers: What's the most confusing production bug you've encountered, and what turned out to be the actual cause?

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & G

Sat, 10 Oct 2026 22:36:18 +0000

Bleeding-Edge Python on Windows: Overcoming Day-One Setup Hurdles with UV, VS Code, and Git Bash & Gemini AI

Diving into a brand-new major release of a programming language is always exciting, but it comes with a unique set of pioneer challenges. Recently, a few hours ago I embarked on setting up a professional Python development environment on Windows utilizing Git Bash, VS Code, uv, the GitHub CLI (gh), and modern Python libraries like Typer, Rich, and GitPython to build automated command-line tools.

Along the way, I ran into several classic developer roadblocks—from missing binary wheels to environment path mismatches and authentication overrides. Here is a look at the challenges I faced, why they happened, and how I successfully conquered them, with the assistance of Gemini AI. I simply copied & pasted the error messages I got from the terminal into the chat with Gemini AI

1. The Bleeding-Edge Trap: Python 3.15 and Package Compatibility

The Challenge

With the very recent release of Python 3.15.0, developers stepping onto this version gain access to the latest core improvements. However, a brand-new release creates an immediate ecosystem lag: third-party package maintainers have not yet uploaded pre-compiled binary wheels (cp315) to PyPI for every library.

When attempting to install dependencies like PyYAML, pip fell back to building the package from source. Because My Windows lacked the heavy C++ compiler toolchain required to compile those C extensions, the installation failed with a frustrating subprocess error.

The Solution

I unpacked how Windows handles Python versions—realizing that installing a new version installs it side-by-side rather than overwriting older ones. To bypass compilation nightmares without manually downloading Visual Studio C++ Build Tools, I leveraged uv, a lightning-fast Python package and project manager, to streamline execution and environment control.

2. Navigating Shell Environments and Virtual Environment Paths

The Challenge

Moving between different shells (PowerShell vs. Git Bash) and workspace directories introduced a series of path and execution hiccups:

Command Not Found: Installing uv via one shell method left it missing from Git Bash's system PATH.
The .venv Trap: VS Code occasionally saved working script files (scaffold.py and inspector.py) directly inside the hidden .venv/Scripts/ folder instead of the root project workspace.
Environment Mismatches: Running standard python triggered global execution rather than the virtual environment, leading to ModuleNotFoundError for packages like Typer despite them being installed elsewhere.

The Solution

I ironed out a reliable workflow by treating Git Bash and virtual environments with precision:

Module-Level Execution: When global paths weren't exposed, I invoked uv directly through the active Python binary (python3.15 -m uv).
Explicit Targeting: I locked down package installations directly to the virtual environment using --python .venv/Scripts/python.exe.
Workspace Hygiene: I located misplaced scripts using file search commands and realigned them to the root ~/WebDevelopment/Python/ directory.

3. The GitHub CLI Authentication Override

The Challenge

With the project scaffolding script (scaffold.py) written to automatically initialize Git repositories and push them live using the GitHub CLI (gh), running a status check revealed an unexpected roadblock:

X Failed to log in to github.com using token (GITHUB_TOKEN)
- The token in GITHUB_TOKEN is invalid.

Even though my Github account (QMS85) was properly saved in the secure system keyring, a stale or rogue GITHUB_TOKEN environment variable was lingering in the active terminal session, overriding the keyring lookup.

The Solution

The fix was wonderfully simple once identified: I had to clear the conflicting shell variable with a single command:

unset GITHUB_TOKEN

Immediately following this, gh auth status successfully recognized the secure keyring credentials, giving our custom automation scripts full, frictionless access to create public repositories and push code straight to GitHub.

Summary: A Production-Ready Workflow

By diagnosing these hurdles methodically, we turned potential frustrations into a robust, high-performance engineering environment:

Fast Dependency Management: Powered by uv for lightning-quick package handling.
Modern CLI Engineering: Leveraging Typer for command-line parsing, Rich for gorgeous terminal UI formatting, and GitPython for repository automation.
Seamless Version Control: Integrated local Git tracking with automated remote publishing via the GitHub CLI.

Whether you are building internal developer tools or public utilities, setting up a solid foundation ensures that when you code on the bleeding edge, you stay completely in control & You can make use of A.I if you get stuck or need sme debugging assistance....

Have you installed the latest version of Python 3.15??
What challenges have you faced?
Which is your preferred A.I/LLM Tools To Use ???
Have used An AI/LLM to help you with debugging, whilst busy in the terminal???

# Debugging ZORGAX: We Captured the Tool-Calling Loop Between Open WebUI and Ollama

Sat, 10 Oct 2026 03:09:08 +0000

Debugging ZORGAX: We Captured the Tool-Calling Loop Between Open WebUI and Ollama

From 28 repeated function calls to a successful end-to-end test — and a new hypothesis about context-window limits.

Introduction

In my previous article, Building ZORGAX: Turning a Local LLM into a DevOps AI Agent, I described our effort to transform a local language model into a controlled infrastructure assistant for the MyZubster ecosystem.

ZORGAX runs on Ollama, uses a custom model based on Qwen 2.5 3B, and connects to Open WebUI inside a Docker-based environment.

Our objective is not to give AI unrestricted control over a server. We want an assistant capable of observing infrastructure, explaining problems, and eventually performing carefully authorized operations.

But we encountered a problem that made one thing clear:

An AI agent that knows how to call a tool must also know when to stop.

When ZORGAX called list_automations, the tool correctly returned an empty list. Yet the agent repeatedly called the same function instead of giving a final answer.

In earlier tests, we observed 28 repeated calls, followed by another run with 16 calls.

This article documents how we investigated that behavior, what we verified, and why the root cause is still an open research question.

1. The original problem

We asked ZORGAX to check active automations.

The tool returned:

{
  "automations": [],
  "total": 0
}

The expected answer was straightforward:

There are currently no active automations.

Instead, ZORGAX kept invoking list_automations.

For a read-only function, unnecessary repetition wastes time and computing resources.

For a future DevOps agent with permission to restart services, deploy software, or modify infrastructure, uncontrolled repetition could be much more serious.

We therefore decided to investigate the entire tool-calling workflow before enabling additional operational capabilities.

2. Testing ZORGAX directly through Ollama

Our first experiment bypassed Open WebUI.

We constructed a synthetic tool-calling conversation using Ollama's /api/chat endpoint.

The sequence contained a user request, an assistant function call, and a matching tool response containing the empty automation list.

ZORGAX completed the interaction successfully.

It generated a final answer and did not request another tool call.

This showed that the model could handle an empty tool response correctly.

However, the direct experiment used a simplified context. It was not identical to the original Open WebUI interaction, so it could not establish which component was responsible for the loop.

3. A suggestion from the developer community

After publishing the first article on Coder Legion, a commenter, lisarconnect, suggested capturing the actual request sent to Ollama immediately after the first tool response.

The key question was:

Does the next request preserve the assistant's tool call and the corresponding tool result?

This gave us a concrete investigation strategy.

Instead of guessing whether the problem came from Qwen, Ollama, or Open WebUI, we could inspect the integration boundary directly.

We also wanted to distinguish a successful empty result from a tool execution error.

Those two situations should not trigger the same behavior.

4. Inspecting Open WebUI's tool-call handling

We examined the installed Open WebUI source and identified the code responsible for continuing conversations after tool execution.

We then tested its actual convert_output_to_messages() function using a synthetic fixture.

The conversion preserved the expected structure:

[
  {
    "role": "assistant",
    "content": "",
    "tool_calls": [
      {
        "id": "zorgax-test-001",
        "type": "function",
        "function": {
          "name": "list_automations",
          "arguments": "{}"
        }
      }
    ]
  },
  {
    "role": "tool",
    "tool_call_id": "zorgax-test-001",
    "content": "{\"automations\":[],\"total\":0}"
  }
]

The assistant tool-call identifier matched the tool-result identifier.

The empty result was preserved.

This was an important finding, but it covered only the isolated message-conversion function.

We still needed evidence from the actual HTTP requests reaching Ollama.

5. Building a separate diagnostic environment

To avoid affecting the main MyZubster installation, we deployed a separate Open WebUI instance.

We also configured:

CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS: "3"

In the Open WebUI build we inspected, the default tool-call iteration limit was 256.

Reducing that limit helped prevent another long-running diagnostic loop.

It was a safety measure, not a fix for the underlying behavior.

We kept operational tools disabled and used a harmless simulated automation function.

class Tools:
    def list_automations(self) -> dict:
        """Return a synthetic empty automation list."""
        return {
            "automations": [],
            "total": 0
        }

This function performs no infrastructure operation. It always returns the same predictable result.

6. Capturing the real Open WebUI → Ollama requests

We created a temporary HTTP proxy between the diagnostic Open WebUI instance and Ollama.

The proxy forwarded requests while recording structural information such as:

Model name
Available tool names
Message roles
Tool-call identifiers
Presence of the simulated empty result

We intentionally avoided logging complete private prompts and credentials.

One earlier captured request advertised approximately 35 built-in tools.

That was very different from our successful direct Ollama test, which exposed only list_automations.

We also reproduced the repeated-call behavior in the isolated Open WebUI environment, where it stopped after reaching the configured three-iteration limit.

At this stage, the number of tools became an interesting variable to investigate.

But correlation is not causation.

We had not yet demonstrated that having many available tools caused the repeated calls.

7. The successful end-to-end experiment

We created a diagnostic model configuration called ZORGAX Diagnostic and enabled only one harmless tool.

Then we asked:

Controlla quali automazioni sono attive usando list_automations. Se non ce ne sono, dimmelo.

This time, ZORGAX called the tool once and responded correctly:

Non ci sono automazioni attive.

The proxy captured the complete follow-up structure.

The first request exposed:

Tools: ['list_automations']
Messages: ['user']

The next request contained:

Tools: ['list_automations']
Messages: ['user', 'assistant', 'tool']
Empty automation result: True

This was the evidence we had been looking for.

Open WebUI successfully transmitted the assistant tool call and the empty tool result to Ollama, and ZORGAX produced a final answer.

We later repeated the successful single-tool experiment.

The proxy again confirmed that the tool result reached Ollama and that ZORGAX completed the task.

This does not solve the original loop, but it substantially narrows our investigation.

8. A second hypothesis: context-window truncation

Another Coder Legion commenter, Mike Dabydeen, suggested examining the model's available context window.

His hypothesis was that a conversation containing a system prompt, extensive tool definitions, and chat history might exceed the available context.

If older messages are truncated, the model might receive the latest tool result without sufficient context to understand the original request.

That could potentially explain repeated tool calls.

We investigated the Ollama configuration.

Our environment uses:

Ollama version: 0.32.14
Model: zorgax:latest

The ZORGAX Modelfile does not explicitly specify num_ctx.

The Ollama service also does not explicitly configure OLLAMA_CONTEXT_LENGTH.

After running a diagnostic inference, we queried the loaded model:

NAME             PROCESSOR    CONTEXT
zorgax:latest    100% CPU     4096

We confirmed that the successful single-tool test operated with a 4096-token context window.

We also updated our diagnostic proxy to record explicitly supplied values of num_ctx and num_predict.

The logging worked correctly.

For real requests generated by our diagnostic Open WebUI configuration, num_ctx was not explicitly present in the captured request options.

That is different from saying the model had no context limit. Ollama still allocated a context window, as confirmed by ollama ps.

What remains unverified

We have not yet captured evidence that Ollama actually truncated messages during the problematic 35-tool interaction.

We have also not completed a controlled comparison of the same tool workload at 4096 versus 8192 tokens.

Context truncation is therefore a plausible hypothesis, not our final diagnosis.

The next experiment must keep the model, system instructions, tool schemas, and user request as consistent as possible while changing one variable at a time.

9. What these experiments taught us

The investigation revealed three separate questions that matter for reliable AI agents.

First: Did the tool execute correctly?

An empty list can be a successful result. It must not automatically be treated as an error.

Second: Did the result reach the language model?

The conversation should preserve the relationship between the assistant's tool call and the tool's response.

Third: Did the model use the result correctly?

Even a correctly transmitted response does not guarantee that a model will stop calling tools.

All three stages need independent testing.

For infrastructure agents, safeguards must also exist outside the model:

Restricted tool permissions
Bounded execution and retries
Duplicate-call detection
Idempotent operations where applicable
Human authorization for consequential actions
Auditable execution results

A prompt instruction saying “do not repeat the tool call” is not a substitute for these controls.

10. Opening the investigation to contributors

We have published our diagnostic findings in the public MyZubster repository.

GitHub investigation issue:

https://github.com/MyZubster-Ecosystem/myzubster/issues/1577

Technical reproduction guide:

https://github.com/MyZubster-Ecosystem/myzubster/blob/main/docs/zorgax/TOOL-CALLING-INVESTIGATION-2026-10-09.md

Developers working with Ollama, Open WebUI, Qwen, Python, or local AI agents are invited to reproduce the experiments.

Useful contributions include controlled context-window comparisons, tool-schema experiments, sanitized HTTP request analysis, and regression tests for empty results and repeated calls.

Contributors can use their own systems. No access to the MyZubster production VPS or private infrastructure is required.

Conclusion

We started with an AI agent repeatedly invoking a function that had already returned a valid result.

We now have a working diagnostic environment, a trace of the actual tool-result continuation, and two successful end-to-end single-tool experiments.

We have also confirmed a 4096-token context allocation and identified a new hypothesis worth testing.

The root cause of the original loop remains open.

That is an important distinction.

We are not claiming that we have fixed a bug simply because one controlled configuration works.

We are building an evidence-based process to understand why the integration behaves differently under different conditions.

For ZORGAX, the objective remains unchanged: create a useful local DevOps assistant that operates within clear security boundaries and earns trust through reproducible tests.

The next milestone is a controlled 4096-versus-8192 context experiment with safe tool fixtures.

Thanks to lisarconnect and Mike Dabydeen for their technical suggestions and to everyone following the MyZubster development process.

The investigation continues in public.

Project: MyZubster Ecosystem
Agent: ZORGAX
Stack: Ollama, Qwen 2.5 3B, Open WebUI, Docker, Python, Ubuntu
Status: Experimental; root cause under investigation

Build in public. Test with evidence. Keep humans in control.

Debugging scroll anchoring when a prepended feed shifts

Fri, 09 Oct 2026 19:59:45 +0000

If a feed prepends new rows while someone is reading older ones, inspect the scroll container before adding JavaScript to adjust its offset. Chromium may already be compensating for the inserted height through scroll anchoring. A transform on the relevant path can suppress that compensation, producing a jump even though the prepend code did not change.

Reproduce the two states

Save this as scroll-anchor.html and open it in Chromium. Click Prepend after the list settles. Then open the same file with ?suppressed=1 and repeat. The two runs differ only in the transform applied immediately before the insertion.

<button id="prepend">Prepend</button>
<div id="viewport" class="viewport"><ol id="feed"></ol></div>
<style>
  .viewport { height: 300px; overflow: auto; }
  .viewport.transform-shift { transform: translateY(0); }
  #feed li { min-height: 72px; }
</style>
<script>
  const viewport = document.querySelector('#viewport');
  const feed = document.querySelector('#feed');
  for (let index = 0; index < 30; index++) {
    const row = document.createElement('li');
    row.textContent = `Message ${index + 1}`;
    feed.append(row);
  }
  feed.children[16].scrollIntoView({ block: 'center' });

  document.querySelector('#prepend').addEventListener('click', () => {
    const before = viewport.scrollTop;
    if (location.search.includes('suppressed=1')) {
      viewport.classList.add('transform-shift');
    }
    const row = document.createElement('li');
    row.textContent = 'New message';
    feed.prepend(row);
    requestAnimationFrame(() => {
      console.log({ before, after: viewport.scrollTop });
    });
  });
</script>

With anchoring enabled, the browser should increase scrollTop to keep the same message near its prior viewport position. With the transform applied, the controlled Chromium fixture used for the original article leaves the offset unchanged, so visible content moves. Compare both the measured offset and the message in view; a single number alone can hide what the reader experienced.

Decide whether to keep anchoring

If the feed should preserve the current reading position, investigate transforms on the scroller and its ancestors before adding manual scroll correction. If movement is intentional, overflow-anchor: none is the explicit CSS opt-out. Apply it only to the section where that behavior is wanted, then retest insertion and focus behavior. Avoid disabling anchoring across a whole page to hide a local layout problem.

This example is a small browser fixture, not a recipe for virtualized lists. The recorded independent test ran in Chromium on Linux; it does not establish identical results in other browsers or in a framework's scrolling abstraction. The MDN scroll anchoring overview describes suppression triggers, and the MDN overflow-anchor reference covers the opt-out.

Read the full article and view the tested screenshots

The bug that survived being recycled: automaticallyAdjustKeyboardInsets and Fabric view recycling on iOS

Thu, 08 Oct 2026 09:12:17 +0000

After logging a meal in Anovi, the nutrition app I build, the next screen opened normally. The content was there. Then the first scroll ran past the end of it, into empty space that should not have existed, and stopped.

Dragging in that space did nothing. Not a slow scroll, not a bounce. Nothing moved, because there was nothing under my finger. The content was somewhere above me and there was no way to reach it. The only way out was to kill the app.

It was not every screen and not every time, which is what kept it alive through earlier rounds of testing. It produced no crash, no error, and no failed request.

In short. On iOS with the New Architecture, a scroll view that opted into keyboard inset handling can leave that behaviour switched on when React Native recycles it. The next screen to inherit that view gets a phantom inset it never asked for. Filed as react-native#57755.

If you just want to check and fix your own app, that is a separate, shorter piece.

The evidence that was missing

Every request in the sequence returned what it should, in the time it should. Nothing failed, nothing timed out, nothing appeared in the logs at the moment things went wrong. The app had not crashed and was not in an error state.

Healthy logs are usually read as the absence of a finding. Here they were the finding, because they eliminated the entire category I had been searching in. That is what promoted the next detail from background noise to the only lead.

The next detail was the keyboard. On the broken screens it appeared, briefly, and went away again. On a screen with no text input on it and nothing focused.

A keyboard reacting where there is nothing to type into is not a rendering bug. Something was still listening.

The screen that broke was not the screen at fault

React Native's new architecture recycles native views. Rather than destroying a component's native view and building a fresh one, it resets the existing view and hands it to the next component that needs the same kind. On iOS, that reset happens in a method called prepareForRecycle.

Recycling is only safe if the reset is complete. Anything left behind belongs to whoever inherits the view next.

A scroll view can opt into having iOS adjust its insets when the keyboard moves, with a prop called automaticallyAdjustKeyboardInsets. Underneath, that sets a flag on the native view and gates a keyboard observer that lives for as long as the view does. prepareForRecycle does not clear that flag.

So the broken screen was innocent. It had no text input, no keyboard props, and nothing to do with any of this. It had simply been handed a view that came out of the pool still holding someone else's settings.

Where the keyboard came from

The view came from the meal logging modal, which does have a scroll view with the prop set and a search field that focuses itself.

The interesting part is what happened when I closed it. Tapping Done dismissed the keyboard, reset the modal's internal flow back to its search step, and hid the modal, all in the same render batch. Resetting the flow remounted the search field, its autoFocus fired, and the app opened a keyboard inside a modal that was already closing.

That is the flicker. Not a leftover from typing, but a keyboard my own code summoned into a dying screen. Its scroll view then went into the recycle pool while that keyboard was still up.

None of that is a bug. A keyboard being up while a screen goes away is ordinary, and the framework is meant to survive it. What it did instead was hand the next screen a view that was still holding the last one's settings.

Building something that fails on demand

An explanation that only reproduces inside a nutrition app is not much use to anyone, and it is not something a framework maintainer can act on. So the next step was the smallest thing that still fails: a modal with the prop and a focused input that kills itself mid-animation, then a plain scroll view that mounts straight afterwards and reports its own geometry.

The detector that cried wolf

Getting the measurement right took longer than finding the bug.

The first version reported failures that were not failures. A scroll view settling after a bounce moves on its own, and sampling at the wrong moment records that jitter as displacement. Several iterations went into separating "this view is still settling" from "this view has been moved by something else".

A detector that reports a bug which is not there is worse than no detector, because it makes the real signal unfalsifiable.

Everything downstream of it, including the controls, would have been noise interpreted as evidence.

Once it was honest, the numbers were unambiguous. A scroll view that never asked for keyboard insets, with the keyboard hidden, reporting a bottom inset of 217.3 points. Its content was 840 points tall in a 234 point window, so the furthest it should ever scroll is 606. It went to 823.

Physical iPhone, iOS 26.5.2, Release build, React Native 0.86.2, New Architecture. The victim sets no keyboard props of any kind.

The controls are the argument

A reproducer that fails is a claim. A reproducer that fails, and stops failing when you remove exactly one ingredient, is evidence.

Two controls, each from a freshly killed process. Turn off the inset prop: nothing. Dismiss the keyboard and let it settle before the modal closes: nothing. Each ingredient is necessary and neither is sufficient. The failure needs a view configured for keyboard insets to be recycled while its observer is still live.

Measuring it instead of reasoning about it

Everything so far was inference, from reading source and watching behaviour. The mechanism deserved a measurement, so I instrumented the framework itself: every keyboard delivery logged with the view's address and whether it was on screen or in the recycle pool.

rec-in  view=0x108118c00 ivar=1          entering prepareForRecycle
rec-out view=0x108118c00 ivar=1          leaving it, flag still set
kbd     view=0x108118c00 ivar=1 POOLED
write   view=0x108118c00 bottom=217.3 POOLED    ‚Üê inset written while pooled
props   view=0x108118c00 old=1 new=0 ivar=0     ‚Üê next screen mounts, flag cleared

The write lands while the view is sitting in the pool, 105ms before anything mounts on it. When a screen does mount, the flag is cleared immediately, so the screen you can see is never written to at all.

That ruled out the explanation I had been carrying. An earlier test, where a poisoned view's scroll position moved after I focused an unrelated text field, had looked like proof that the recycled view was still listening while mounted. It was not. The keyboard changed the layout, the window grew from 234 points to 299, the furthest legal scroll position dropped by 65, and iOS pulled the offset back to the new limit. Arithmetic, not a live listener.

What is actually happening

The pooled view keeps receiving keyboard notifications and keeps writing insets onto itself. It is not stale; it is current. It tracks the keyboard continuously, taking a real value when a keyboard rises and zero when it falls.

Whatever value it happens to be holding at the moment someone inherits it is what that screen is stuck with, because the inset is only reassigned when a component's props change it, and a component that never set the prop has nothing to reassign.

Which means the whole thing turns on timing. Sweeping the delay before the modal tears itself down, ten cycles each from a fresh process:

modal torn down after	corrupt readings	phantom inset
~120ms	36	217.3
~220ms	0	0.0
~320ms	0	0.0
~520ms	0	0.0
keyboard dismissed first	0	0.0

Only the earliest teardown reproduces. Wait longer and the keyboard's own disappearance reaches the pooled view first, zeroes the inset, and the pool quietly cleans itself. The bug needs a screen to mount during the narrow window while a keyboard is up.

That is also why it was intermittent in production, and why it survived earlier testing rounds. Most of the time nothing mounts inside that window.

Why it could not be scrolled back

The phantom inset extends the scrollable range past the end of the content, and that extra region has no view underneath it. So it takes no touches. A drag there produces no scroll events at all.

In the reproducer a sliver of the last row stays visible, so you can grab that and pull yourself back. In the app the scroll views were full screen. Once the content had left the viewport there was nothing to grab, and no gesture in the app could recover it.

A screen recording of the reproducer on a physical device is on the original article: several poison cycles, a scroll up into the space that should not exist, then taps on an unrelated input.

That is the difference between a layout glitch and a screen that is finished until you kill the process.

What happened after filing

I reproduced it unchanged on React Native 0.86.2, the latest release at the time, and filed it as react-native#57755 with a public reproducer.

Two pull requests followed, from people I have never met. The second carries a regression test covering the whole lifecycle, and a Meta engineer imported it for internal review the same morning it appeared.

Its two lines are small: clear the flag when the view is recycled, and stop guarding the assignment behind a props comparison so a recycled view can be re-armed properly. I applied them to the reproducer and ran it on the phone that found the bug in the first place. Baseline immediately before: 36 corrupt readings in 10 cycles. With the patch: 49 cycles, zero.

What I would take from this

The healthy logs were the finding. They eliminated a whole category, which is what turned a flicker into the only lead.

Controls before claims. Any bug can be explained by a plausible story. The question is which single ingredient you can remove to make it stop, and whether you have actually tried removing it.

A detector that lies is worse than no detector. Most of the reproducer work went into eliminating false positives, not into finding the failure.

Instrument the explanation, not just the bug. A story that fits every observation is not the same as a correct one. Mine was in the right place and the wrong moment, and only logging the framework showed the difference.

If you think your own app has this, the checks and the three ways to fix it are in a shorter companion piece.

The reproducer is at github.com/PragathiJ/rn-aaki-recycle-repro.

I write about production engineering and applied AI at pragathijayaram.com.

automaticallyAdjustKeyboardInsets is leaking into your other screens: how to check and fix it

Thu, 08 Oct 2026 08:56:07 +0000

A screen opens normally, then scrolls past the end of its content into empty
space, and dragging in that space does nothing at all. Restarting the app is the
only way out.

If that sounds familiar, this is a React Native framework defect, not your code.
This page is the operational version: how to confirm it, how to find every source
in your project, and what to do. The investigation behind it, including why it
took a while to understand, is here.

Scope. iOS only, New Architecture only. The code involved is the Fabric iOS
scroll view, so the old architecture and Android take different paths.
Reproduced on React Native 0.81.4 and 0.86.2. Filed as
react-native#57755.

What is going wrong

A scroll view that sets automaticallyAdjustKeyboardInsets keeps that behaviour
switched on when React Native recycles its native view. While the view sits in the
recycle pool it carries on receiving keyboard notifications and writing insets
onto itself. The next component to be handed that view inherits whatever value was
there, and nothing puts it back, because a component that never set the prop has
no inset of its own to assign.

The result is a scroll view with extra scrollable space below its content. That
space has no view underneath it, so it takes no touches, which is why you cannot
drag your way back out of it.

Confirm it

The first sign is a keyboard appearing on a screen with nothing focused. That is
the tell, not the bug.

The test is to read the inset on a scroll view that should not have one. Put this
on a screen that sets no insets of its own, scroll it with the keyboard hidden,
and watch the console:

const reported = React.useRef(false);

<ScrollView
  scrollEventThrottle={16}
  onScroll={(e) => {
    // contentInset is iOS-only; on Android nativeEvent has no such field.
    const bottom = e.nativeEvent.contentInset?.bottom ?? 0;
    if (bottom > 0 && !reported.current) {
      reported.current = true;
      console.warn('phantom bottom inset', bottom);
    }
  }}
>
  <View style={{ height: 2000 }} />
</ScrollView>;

Two details decide whether this test is worth anything. The scroll view needs
content taller than itself, or it never scrolls, onScroll never fires, and you
will conclude you are clean without having tested anything. And the reading has to
be gated, because at a 16ms throttle an ungated console.warn buries your log.

A scroll view that never opted in should report zero. Anything else means it is
sitting on a view that came out of the pool still armed.

Find every source

grep -rn "automaticallyAdjustKeyboardInsets" src/
grep -rn "contentInset" src/   # also catches contentInsetAdjustmentBehavior

The second search matters more than it looks. Any prop that writes native insets
belongs to the native view, and therefore to the recycling pool, so a static
contentInset combined with an automatic contentInsetAdjustmentBehavior is the
same class of risk even though it has nothing to do with keyboards. In my own
sweep that turned up a grid component the first search had missed.

Then run both again against node_modules. The pool is per process, not per
module, so a scroll view inside a dependency arms it exactly as well as one of
yours. You can clean your own code completely and still be handed a poisoned view by a library you did not write.

Fix it

Option 1, remove the prop. Handle keyboard layout explicitly instead. This is
what I shipped.

// Before: the flag does the layout, and the native view keeps listening
<Modal visible={visible}>
  <ScrollView automaticallyAdjustKeyboardInsets>
    <TextInput autoFocus />
  </ScrollView>
</Modal>

// After: explicit layout, nothing left armed on the native view
<Modal visible={visible}>
  <KeyboardAvoidingView behavior="padding" style={{ flex: 1 }}>
    <ScrollView contentContainerStyle={{ paddingBottom: 24 }}>
      <TextInput autoFocus={visible} />
    </ScrollView>
  </KeyboardAvoidingView>
</Modal>

The autoFocus={visible} change matters more than it looks. Focusing on mount is
what starts a keyboard animation during modal presentation, which is exactly the
window the defect needs. Watch for the same shape anywhere a modal resets its
internal state as it closes: that can remount a focused field and open a keyboard
inside a screen that is already going away.

One caveat: KeyboardAvoidingView with behavior="padding" inside a Modal
behaves differently depending on presentation style and often wants a
keyboardVerticalOffset. Treat it as a shape to adapt, not a drop-in.

Option 2, keep the prop but dismiss the keyboard first. Dismiss it and let it
settle before the screen unmounts. This came back at zero in the reproducer. It is
narrower than option 1, because it depends on every exit path from that screen
doing the same thing.

Option 3, patch the framework locally. Until the upstream fix ships you can
carry it as a patch-package patch. In RCTScrollViewComponentView.mm, clear the
flag on recycle and assign it on every update instead of only when it changes:

// prepareForRecycle: disarm before the view goes back in the pool
_automaticallyAdjustKeyboardInsets = NO;

// updateProps: drop the old-vs-new condition around the assignment
_automaticallyAdjustKeyboardInsets = newScrollViewProps.automaticallyAdjustKeyboardInsets;

Both lines are needed. The first stops the leak. The second matters because
prepareForRecycle does not reset the stored props, so once the flag is cleared a
view being reused by another component that also wants keyboard insets would
skip the assignment and silently lose the behaviour.

This is the substance of react-native#57811, which a Meta engineer has imported for internal review. I verified those changes against the reproducer on a physical device: 49 cycles, zero failures, where the unpatched build produced 36 failures in 10 cycles.

If you are on 0.86.2 and patching the framework, note that React core ships
prebuilt, so edits to RCTScrollViewComponentView.mm in node_modules never
reach the binary. You need RCT_USE_PREBUILT_RNCORE=0 and a fresh pod install,
or the patch silently does nothing.

What does not work

Scrolling the screen back to the top when it opens. I shipped that early and it
does clear the wrong opening position, which is enough to make it look like a
cure. It does not remove the phantom inset, so the dead space is still waiting at
the bottom.

How to tell you have fixed it

Run the confirmation check again after the flow that used to break things. Zero
inset, and a scroll to the bottom that stops at the end of your content with
nothing beneath it.

The reproducer is at
github.com/PragathiJ/rn-aaki-recycle-repro.

I write about production engineering and applied AI at
pragathijayaram.com.

Fixing KV Propagation Delay in Media Publishing

Wed, 07 Oct 2026 06:02:44 +0000

When you build a serverless media pipeline that stores generated images in a key-value store and immediately sends those public URLs to a third-party publishing API, you will likely encounter a frustrating failure mode. Your local tests pass, your terminal curl requests return the correct image bytes with a 200 OK status, yet the publishing API responds with a cryptic media not found error. This happens because your own worker reads from the exact edge location that just wrote the key, while the platform fetcher hits a different edge node that has not received the replicated data yet. For a related implementation, see Viewmodel Partial Success Refresh Failure.

Green Locally, Dead Remotely

The most deceptive part of this issue is its misleading diagnostic feedback. When publishing fails, the natural instinct is to examine the container ordering, parameter payloads, or authentication tokens. Developers often curl the generated public URL from their own workstation or test runner, receive the correct MIME type and image bytes, and conclude that the serving layer works fine. This self-verification is a trap. Your edge succeeding proves only that one specific node has the data. It provides zero visibility into whether the global key-value fabric has synchronized across all regional datacenters.

Whose Edge Is It Anyway

Global key-value stores prioritize low-latency writes and eventual consistency. When your worker executes a put operation, the runtime confirms success once the local write succeeds. Replication to other regions happens asynchronously in the background. If a third-party platform attempts to download the asset immediately after receiving the URL, its request routes to an edge server near its own infrastructure. If that specific server has not received the update, the fetch fails. Because distributed platforms do not expose their internal replication state or routing tables, you cannot poll their edge directly to check availability. You must instead build a defensive timing model into your application code.

Two Waits, Two Handoffs

Solving this problem requires separating your publishing pipeline into distinct phases, each guarded by its own deliberate delay. Conflating these phases leads to brittle workarounds.

The Propagation Wait: After storing the asset in key-value storage, introduce a measured pause to allow global replication. This gives remote edge locations time to catch up before any external system attempts a download.
The Processing Wait: After the third-party platform initiates its import or container creation process, allow an additional window for the platform to process the file before you invoke the final publish command.

Hardcoding these delays into your core logic makes your test suite painfully slow. Instead, make your wait durations configurable by injecting milliseconds during testing while using production-appropriate values for live deployments. Keeping these constants clearly named in your source code prevents future maintainers from accidentally optimizing them away.

Implementing the Fix

To manage these handoffs safely, structure your asynchronous worker code to wait explicitly between storage and publishing steps. Here is an example configuration pattern in TypeScript that uses injected wait durations:

interface PublishConfig {
  propagationDelayMs: number;
  processingDelayMs: number;
  maxRetries: number;
}

async function storeAndPublishMedia(
  kv: KVNamespace,
  key: string,
  data: ArrayBuffer,
  config: PublishConfig
): Promise<string> {
  await kv.put(key, data);
  
  // Guard against global edge replication lag
  await new Promise((resolve) => setTimeout(resolve, config.propagationDelayMs));
  
  const mediaId = await initiatePlatformUpload(key);
  
  // Guard against remote processing lag
  await new Promise((resolve) => setTimeout(resolve, config.processingDelayMs));
  
  return await finalizePublish(mediaId);
}

Verifying the Publish Object

Never rely on your own curl command as proof of a successful publish operation. True success is defined solely by the response of the downstream publishing API. When the platform successfully fetches the asset from its local edge, processes it, and returns a valid media object with attached children or confirmation IDs, your pipeline has succeeded. If the call fails, adjust your propagation budget upward or inspect the platform error logs for download timeouts.

Final Thoughts

Eventual consistency models introduce hidden timing assumptions into modern serverless architectures. When your application hands off assets to external consumers, assuming instant global visibility will cause intermittent failures. By acknowledging edge propagation realities, separating your storage waits from your processing waits, and verifying platform objects rather than local URLs, you can make your media publishing pipelines resilient to distributed latency.

Debugging Salesforce Apex - 8 Gotchas That Waste Everyone's Weekend

Tue, 29 Sep 2026 18:45:24 +0000

title: Debugging Salesforce Apex - 8 Gotchas That Waste Everyone's Weekend
published: true
description: 8 Gotchas That Waste Everyone's Weekend
tags: salesforce, apex, debugging, tutorial

published_at: 2026-07-17 13:16 +0000

If you've ever stared at a Salesforce debug log wondering why a trigger fired twice, why your query "worked yesterday," or why a batch job silently ate an exception — this one's for you.

Apex debugging is different from debugging most languages because you're not just fighting your own code. You're fighting governor limits, an opaque order of execution, and a debug log format that seems designed to hide the one line you need. Here are the gotchas that trip people up most, with real code.

1. Your `catch` block is swallowing the actual error

This is the single most common reason "nothing shows up in the logs":

try {
    insert accounts;
} catch (Exception e) {
    System.debug('Something went wrong');
}

You caught the exception, printed a string with zero context, and moved on. When it breaks in production, you have nothing to go on.

Fix:

try {
    insert accounts;
} catch (DmlException e) {
    for (Integer i = 0; i < e.getNumDml(); i++) {
        System.debug(LoggingLevel.ERROR,
            'DML failed on row ' + e.getDmlIndex(i) +
            ': ' + e.getDmlMessage(i));
    }
    throw e; // don't swallow it unless you have a real reason to
}

Catch specific exception types (DmlException, QueryException, NullPointerException) instead of generic Exception whenever you can — the specific types give you methods like getDmlMessage() and getDmlIndex() that a bare Exception doesn't.

2. Debug logs get truncated at 2MB — and truncate from the middle

Salesforce debug logs have a hard 20MB size cap per transaction, but the piece you actually read in Setup often gets cut around 2MB depending on log level. When a log is huge, Salesforce removes lines from the middle, not the end — so you'll see the start of your transaction and the finish, with the actual bug missing.

Fix: Don't set every category to FINEST. Set only what you need:

APEX_CODE: DEBUG (not FINEST)
DB: INFO
WORKFLOW: INFO
VALIDATION: INFO
CALLOUT: INFO

FINEST on APEX_CODE logs every variable assignment and method entry/exit — it's the fastest way to blow past the size limit and lose the exact line you care about.

3. Governor limits don't show up until they blow up

Apex is multi-tenant, so you get hard caps: 100 SOQL queries, 150 DML statements, 10,000 SOQL rows, 10 seconds of synchronous CPU time. The gotcha isn't that limits exist — it's that code that looks fine in isolation fails the moment it runs in bulk (more on that in #4).

Instrument before you hit the wall:

System.debug('SOQL queries used: ' + Limits.getQueries() + ' / ' + Limits.getLimitQueries());
System.debug('DML used: ' + Limits.getDmlStatements() + ' / ' + Limits.getLimitDmlStatements());
System.debug('CPU time: ' + Limits.getCpuTime() + ' / ' + Limits.getLimitCpuTime());

Drop these at the top and bottom of suspect methods. When someone says "it works for one record but times out on a bulk import," this is how you find out where.

4. SOQL/DML inside a `for` loop — the classic that still gets everyone

// DO NOT DO THIS
for (Contact c : triggerNew) {
    Account a = [SELECT Id, Name FROM Account WHERE Id = :c.AccountId]; // query in a loop
    a.Last_Contact_Date__c = Date.today();
    update a; // DML in a loop
}

This passes code review constantly because the person testing it only inserted one record. Insert 200 Contacts via a Data Loader batch and you'll blow past the 100-query or 150-DML limit instantly.

Fix — bulkify it:

Set<Id> accountIds = new Set<Id>();
for (Contact c : triggerNew) {
    if (c.AccountId != null) accountIds.add(c.AccountId);
}

Map<Id, Account> accountsToUpdate = new Map<Id, Account>(
    [SELECT Id, Name FROM Account WHERE Id IN :accountIds]
);

for (Contact c : triggerNew) {
    if (accountsToUpdate.containsKey(c.AccountId)) {
        accountsToUpdate.get(c.AccountId).Last_Contact_Date__c = Date.today();
    }
}

update accountsToUpdate.values();

One query, one DML statement, regardless of batch size.

5. `Test.startTest()` / `Test.stopTest()` reset limits — this can hide real bugs

@isTest
static void testBulkInsert() {
    List<Account> accs = TestDataFactory.createAccounts(200);
    Test.startTest();
    insert accs;
    Test.stopTest();
    // asserts...
}

Test.startTest() gives you a fresh set of governor limits and forces async work (@future, queueables, batch chunks) to run synchronously inside stopTest(). That's great for testing async logic — but it also means limit-related bugs that would show up in a single real transaction can hide inside your test because the limits reset partway through. If a bug only appears in production and never in tests, check whether your DML/queries are split across the startTest/stopTest boundary in a way production traffic never gets.

6. Relationship field queries return `null`, not an exception — until you touch a field on them

Contact con = [SELECT Id, Account.Name, Account.Owner.Email FROM Contact WHERE Id = :conId];
System.debug(con.Account.Name); // fine if Account exists
System.debug(con.Account.Owner.Email); // NullPointerException if Account is null

If AccountId is null on that Contact, con.Account itself is null — and reaching for .Owner on a null Account throws a NullPointerException with a stack trace that just says "line 47," giving you no hint about which relationship was null.

Fix: Guard each hop, or flatten with a null-safe pattern:

String ownerEmail = (con.Account != null && con.Account.Owner != null)
    ? con.Account.Owner.Email
    : null;

7. `without sharing` vs `with sharing` causes silent missing data, not errors

public without sharing class DataProcessor {
    public List<Account> getAccounts() {
        return [SELECT Id, Name FROM Account]; // sees ALL records, ignores sharing rules
    }
}

The dangerous version of this bug is the reverse: a class declared with sharing (or with no declaration, which inherits the caller's context) queries fewer records than expected for a particular user, and nothing throws an error — the query just returns 3 rows instead of 300. This is brutal to debug because it looks like a data problem, not a code problem.

Fix: When you get a "missing records" bug report, check the sharing keyword on every class in the call stack before you touch the query itself. Explicitly declare with sharing / without sharing / inherited sharing on every class — don't rely on the default.

8. Async debug logs don't show up where you're looking

@future methods, Queueable jobs, and Batch Apex execute in a separate transaction, often minutes later, under a different debug log entry than the one you're staring at.

@future
public static void updateRelatedRecords(Set<Id> recordIds) {
    System.debug('This log will NOT appear in the log of the code that called this method');
    // ...
}

Fix: Set up a trace flag on the user, not just for a single anticipated transaction, and go to Setup → Debug Logs to find the log entry with a later timestamp and an "Application: Async" indicator. For batch jobs, check Setup → Apex Jobs for the Job ID, and consider writing key checkpoints to a custom object or Exception records so you have a permanent record instead of a log that expires.

Quick reference

Symptom	Likely cause
Works with 1 record, fails on bulk import	SOQL/DML inside a loop
Log is huge but missing the actual error	Log level set to FINEST, middle got truncated
NullPointerException with no useful detail	Unguarded relationship field traversal
User reports missing data, no error thrown	Sharing rules / `with sharing` mismatch
`System.debug` never shows up	Code ran in an async context — check Apex Jobs
Passes in test, fails in prod	Test isolated by `startTest`/`stopTest` boundary

Debugging Apex is mostly about knowing where to look — the log level, the sharing context, and whether you're even looking at the right transaction. Get those three things right and most "mystery bugs" stop being mysterious.

What's the Apex bug that took you the longest to track down? Drop it in the comments.

60 % of our image decode failures were HEIC files named .jpg

Mon, 28 Sep 2026 05:02:05 +0000

For a few days our analytics showed a class of failure that made no sense: images rejected by the decoder in well under a second. Not slow failures, not out-of-memory on a huge photo — instant refusals. Between 2026-09-06 and 09-10, 60 % of every decode_failed event came from the same shape of file: an iPhone photo called photo.jpg, reporting image/jpeg, whose actual bytes were HEIC.

We had a HEIC path. It was never tried, because the gate that decides whether to load the HEIC decoder was reading the filename.

Disclosure: this is from LensUp, which is ours. The fix is the boring one — read the bytes — but the interesting part is where naive byte-sniffing then went wrong, and the precedence rule we ended up needing.

How a HEIC ends up called .jpg

Nobody renames these on purpose. The path is mundane: an iPhone shoots HEIC, you share the photo through a messenger or copy it to a PC, and somewhere along the way the transport relabels it. The extension becomes .jpg, file.type becomes image/jpeg, and the container is still HEIC.

From the browser's side there is no hint of this. File.type is not derived from content — it is whatever the OS or the transport asserted. So:

// Cheap, synchronous gate so the page can decide whether to lazy-load the HEIC decoder
// module at all. Byte-level truth lives elsewhere — names and MIME lie often enough
// that this is only a candidate check, never a verdict.
export function isHeicCandidate(file) {
  const mime = file?.type?.toLowerCase();
  if (mime === 'image/heic' || mime === 'image/heif') return true;
  const extension = file?.name?.split('.').pop()?.toLowerCase();
  return extension === 'heic' || extension === 'heif';
}

That function is fine — as a hint for whether to lazy-load a wasm decoder you do not want to ship to everyone. It is not fine as the thing that decides which decoder runs. That was the bug: a hint had been promoted to a verdict.

Sniffing: twelve to sixteen bytes, never the file

The fix reads a small slice. Not the file — a slice:

const FTYP_READ_BYTES = 64;
export async function sniffInputSignature(file) {
  let head;
  try {
    head = new Uint8Array(await file.slice(0, FTYP_READ_BYTES).arrayBuffer());
  } catch { return null; }
  if (head.length < 4) return null;
  const ascii = (from, to) => String.fromCharCode(...head.subarray(from, Math.min(to, head.length)));

  if (head[0] === 0xff && head[1] === 0xd8 && head[2] === 0xff) return 'jpeg';
  if (head[0] === 0x89 && ascii(1, 4) === 'PNG') return 'png';
  if (ascii(0, 4) === 'GIF8') return 'gif';
  if (ascii(0, 4) === 'RIFF' && head.length >= 12 && ascii(8, 12) === 'WEBP') return 'webp';
  if (ascii(0, 2) === 'BM') return 'bmp';
  if (ascii(0, 4) === '%PDF') return 'pdf';
  // … TIFF (II*\0 / MM\0*), then the ISO-BMFF family below
}

Sixteen bytes covers every format the importer accepts, and file.slice() means the read is one small range request against the blob rather than a load of a 12-megapixel photo.

Where "just read the bytes" is not enough

ISO base media files — HEIC, HEIF, AVIF, MP4 and friends — all start the same way: bytes 4–8 spell ftyp, bytes 8–12 carry the major brand. So the naive version is: read the major brand, map heic → HEIC decoder, avif → native.

Then review found the hole. Two of those brands are generic:

const HEIC_BRANDS = new Set(['heic', 'heix', 'hevc', 'hevx', 'heim', 'heis', 'hevm', 'hevs']);
const AVIF_BRANDS = new Set(['avif', 'avis']);
const GENERIC_HEIF_BRANDS = new Set(['mif1', 'msf1']);

mif1 and msf1 mean "this is a HEIF container" and say nothing about the codec inside. An AVIF file may carry mif1 as its major brand and declare avif only further down, in the compatible-brands list. Treat mif1 as HEIC and you hand a file the browser decodes natively — losslessly, instantly — to a lossy wasm transcode. You have recompressed somebody's photo for no reason.

So a generic major brand gets resolved from the compatible brands, and the ftyp box is walked using its own declared size:

if (head.length >= 12 && ascii(4, 8) === 'ftyp') {
  const major = ascii(8, 12).trim().toLowerCase();
  if (HEIC_BRANDS.has(major)) return 'heic';
  if (AVIF_BRANDS.has(major)) return 'avif';
  if (GENERIC_HEIF_BRANDS.has(major)) {
    // ftyp box: [size:4]['ftyp'][major:4][minor version:4][compatible brands:4 each …]
    const boxSize = ((head[0] << 24) | (head[1] << 16) | (head[2] << 8) | head[3]) >>> 0;
    const end = Math.min(head.length, boxSize || head.length);
    const compatible = [];
    for (let offset = 16; offset + 4 <= end; offset += 4) {
      compatible.push(ascii(offset, offset + 4).trim().toLowerCase());
    }
    if (compatible.some((b) => AVIF_BRANDS.has(b))) return 'avif';
    if (compatible.some((b) => HEIC_BRANDS.has(b))) return 'heic';
    return 'heif';   // a HEIF container that names no codec
  }
}

Two details in there that are easy to skip. The box size is clamped with Math.min(head.length, …) so a bogus length cannot walk past the slice we actually read. And when no compatible brand is specific, the answer is the honest 'heif' — "a HEIF container, codec unknown" — rather than a guess.

The precedence rule: bytes win, the label breaks ties

"Always trust the bytes" is the slogan, and it is almost right. The generic-HEIF case is where it breaks: a file whose bytes only say heif could be a HEIC the browser cannot open, or something it can. There is no byte that settles it.

So the rule that shipped is narrower and, I think, the actually correct one: bytes win over the label; the label breaks ties only when the bytes say nothing.

export async function classifyInput(file) {
  const signature = await sniffInputSignature(file);
  const labelPdf  = isPdfCandidate(file);
  const labelHeic = isHeicCandidate(file);
  const labelTiff = isTiffCandidate(file);
  const isPdf  = signature === 'pdf'  || (labelPdf  && signature === null);
  const isHeic = !isPdf && (signature === 'heic' || (labelHeic && (signature === null || signature === 'heif')));
  const isTiff = !isPdf && !isHeic && (signature === 'tiff' || (labelTiff && signature === null));
  return { signature, isPdf, isHeic, isTiff, isImage: !isPdf && !isHeic && !isTiff,
           mislabelled: labelPdf && IMAGE_SIGNATURES.has(signature) };
}

Read the three interesting rows:

scan.pdf whose bytes are a JPEG is an image, not a broken PDF. Before this, those went to the PDF parser and produced pdf_invalid: 39 of them between 09-06 and 09-11, most from Windows desktops retrying the same file over and over — the user's file was fine, our routing was not.
IMG_0001.jpg whose bytes start with %PDF is a PDF. Same rule, other direction.
A generic HEIF goes to the HEIC decoder only if the label agrees. signature === 'heif' && labelHeic → HEIC. A .jpg with those bytes stays on the native path, because that is the case where the label is the only evidence that exists.

One more lie: application/octet-stream

Worth its own line, because it is not a type:

// application/octet-stream is what browsers say when they do not know — treat it as
// undeclared so the extension map (and downstream byte sniffing) can decide.
if (declared && declared !== 'application/octet-stream') return declared;

Windows file pickers hand over .pdf files with an empty or application/octet-stream type often enough that treating it as a real MIME type poisons every branch downstream. It means "no opinion", and the code should say so.

The same file also needs a small alias table, because the same format arrives under several names: image/pjpeg, image/x-ms-bmp, image/x-png, image/jpg. Normalise first, decide second.

What I would take from this

A cheap label check and an expensive byte check are different functions and should be named differently. Our bug was one function doing both jobs — a lazy-load hint named like a verdict. isHeicCandidate and isHeicFile now sit next to each other with comments saying which is which, and that naming is doing more work than the sniffer is.

"Read the bytes" needs a tie-break rule, not just a preference. Some formats genuinely do not identify their own contents. Write the precedence down explicitly — bytes, then label, then a documented default — rather than letting it emerge from the order of your ifs.

Failures that are too fast are a routing smell. A decoder that gives up in 200 ms did not struggle with your file; it was handed the wrong file. That timing was the clue that pointed at the label, and it is the one I will look for first next time.

If you want to see the byte path do its thing, drop a HEIC — renamed or not — into a browser-based document scanner. It runs in the tab and files are never uploaded.

What usually breaks first in production: code, data, or dependencies?

Sun, 27 Sep 2026 06:16:57 +0000

A service can pass every test and still fail in production. The first real issue often comes from one of these:

      unexpected data
      slow or failing dependencies
      retry behavior
      configuration drift
      traffic spikes

In your experience, what breaks first most often? And what signal helps you find it fastest?

Building for the Person Who Can't Debug It

Thu, 24 Sep 2026 13:19:38 +0000

This is the second half of a two-part writeup on an n8n lead-intake workflow.
Part1 covered the Webhook payload break — this one covers the rest of the build.

The first post about this workflow covered the Webhook payload break — the moment the Form Trigger got swapped out and every downstream reference silently pointed at data that no longer existed. That part's done. This is the rest of the build: three smaller decisions that don't share a bug, but do share a reason.

Marisol — the client this workflow was built for — isn't technical. She has no developer on call. If this breaks while she's using it, she's the one looking at it first. That fact didn't come up once and get filed away; it kept showing up, in places that had nothing to do with each other.

Flipping the IF Node

The junk filter was supposed to do one thing: stop a submission if both phone and email were empty, since a lead with neither is useless. The logic in my head was straightforward — "if phone empty AND email empty, stop."

But when I actually built the IF node, I flipped it: "if phone OR email is not empty, continue." Same condition, inverted. What changed was which branch reads as the main path. Written this way, the true branch is the branch I actually follow when I trace the workflow — the valid data moving forward. The false branch is just "nothing happens," which is exactly what it should look like: the door that quietly doesn't open.

It's a small thing. The workflow does the same job either way. But if Marisol — or anyone else — ever opens this node to understand why a lead didn't show up in Sheets, the condition should read like the thing that's actually happening, not like a double negative she has to mentally invert first.

Tested both directions: a submission with both phone and email empty correctly stopped, and a submission with just one filled correctly passed through.

Redesigning the Set Node

Originally, the Set node had exactly one job — default the message field to "No message provided" if it came in empty. That was true right up until the trigger swap.

Once the Webhook replaced the Form Trigger, the payload picked up a lot of extra weight — headers, params, webhookUrl, executionMode, all the raw HTTP metadata that comes bundled with a webhook request. None of it was useful to Sheets or Slack. All of it was now sitting in the same object as the five fields that actually mattered.

I could have left it. The extra keys wouldn't have broken anything downstream — Sheets and Slack only read what I told them to read. But that's exactly the kind of thing that's invisible until someone else has to look at it. So I rebuilt the Set node to do more: explicit mappings for all five clean fields — Name, Phone, Email, Service address, Message — stripping the noise and defaulting the message in the same place.

I chose explicit field mappings over n8n's "keep only set fields" toggle on purpose. The toggle does the same job with less typing, but it hides what's happening — you'd have to open the node and go find the setting to know why the extra fields disappeared. Written out explicitly, the five fields the workflow actually cares about are right there, visible, nothing to go dig for.

Writing the Doc for Marisol

The last piece was the plain-English explanation — the thing Marisol actually reads if something goes wrong. First time writing a doc like this, so I built it around what she'd need, not around what I found interesting to explain: what the workflow does, a step-by-step walkthrough using the real node names (Filter Out Junk Leads, Clean and Format Lead Data — the names she'd see if she ever opened it herself), and a troubleshooting section.

For troubleshooting, I didn't invent hypothetical failure cases — I used one that had actually happened. During testing, the Google Sheets node failed once because the credential needed reconnecting; disconnecting and reconnecting it fixed it. Small thing, but real, and more likely to recur than something exotic I could've made up instead.

The doc and the exported workflow JSON stayed as two separate files, deliberately. The JSON is the actual automation, importable straight into her n8n. The doc is a reference for a human. They don't get merged into each other — that split is what the brief asked for, and forcing them together would've made one file try to do two jobs.

Same Constraint, Three Places

None of these three decisions are related on the surface — an inverted condition, a redesigned node, a document. What ties them together is that each one got shaped by a person who wasn't going to be in the room the next time this workflow needed explaining, and who can't reason through n8n's internals if it breaks. The workflow doesn't get simpler because of that. It gets more legible.

More on how this and other builds come together: tarek-elzoghby.github.io/tarek-elzoghby-hub

How to Fix Firebase `PERMISSION_DENIED` Errors in React Native

Tue, 22 Sep 2026 12:05:03 +0000

If you are using Firebase with a React Native app, sooner or later you will probably run into something like this:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

Or:

Error: PERMISSION_DENIED: Permission denied

And the annoying part is that the error does not tell you much.

It does not say:

Your Firestore rule on this collection is blocking the request.

It just tells you that Firebase rejected it.

That can happen for several different reasons. Your Firestore rules might be doing exactly what you told them to do, your user might not actually be authenticated, App Check might be involved, or your app might be connected to a different Firebase project than you think.

So before changing random rules until the error disappears, it is better to figure out why Firebase is rejecting the request.

First, find out which Firebase service is rejecting the request

PERMISSION_DENIED is not limited to Firestore.

You can see permission-related errors with services such as:

Cloud Firestore
Realtime Database
Firebase Storage
Firebase App Check
Firebase Authentication-related operations

So start by looking at the full error.

For example:

FirebaseError: [code=permission-denied]: Missing or insufficient permissions.

If the stack trace shows a Firestore operation such as:

firestore()
  .collection("users")
  .doc(userId)
  .get();

then your first place to look is Firestore security rules.

If the error happens while uploading a file, Storage rules are more relevant.

This sounds obvious, but a long React Native stack trace can make it easy to focus on the wrong part.

Check your Firestore security rules

If the error comes from Firestore, check your rules first.

For example, you might have:

rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {

    match /users/{userId} {
      allow read, write: if request.auth != null;
    }
  }
}

This rule only allows authenticated users to access documents under:

/users/{userId}

If your app makes the request before the user has signed in, Firebase will reject it.

That can produce:

permission-denied

The important part is that Firebase is not necessarily malfunctioning here.

Your rule may simply be doing exactly what it was written to do.

Check whether the user is actually authenticated

One of the easiest mistakes is assuming that the user is signed in when the request runs.

For example:

const user = auth().currentUser;

console.log(user);

If that prints:

null

then there is no authenticated Firebase user at that moment.

A rule such as:

allow read, write: if request.auth != null;

will reject the request.

This can happen when your app starts up and immediately tries to read Firestore before Firebase Authentication has restored the user's session.

For example, you might have code that effectively does this:

const user = auth().currentUser;

firestore()
  .collection("users")
  .doc(user.uid)
  .get();

If user is not available yet, the request can fail.

Instead, make sure your application waits for the authentication state before making requests that require authentication.

With React Native Firebase, you can listen for authentication changes:

useEffect(() => {
  const unsubscribe = auth().onAuthStateChanged(user => {
    if (user) {
      // Safe to make requests that require authentication
    }
  });

  return unsubscribe;
}, []);

The exact structure depends on your app, but the idea is the same:

Do not assume authentication has finished restoring just because the app has started.

Check that the rule matches the path you are actually using

This is another very common one.

Imagine your rules contain:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

But your app actually accesses:

/profiles/123

That rule does not apply to /profiles/123.

You need a matching rule for the path being accessed.

This becomes especially confusing when you have nested collections.

For example:

/users/123/settings/theme

is not the same path as:

/users/123

Your rules need to match the actual document path.

If you are getting PERMISSION_DENIED, look at the exact collection and document your code is trying to access.

Do not assume the rule you are looking at is the one Firebase is evaluating.

Be careful with nested Firestore documents

Suppose you have:

users/{userId}/settings/{settingId}

You might write:

match /users/{userId} {
  allow read, write: if request.auth != null;
}

and expect that to cover everything underneath the user.

It does not automatically mean that every nested document is covered.

You may need a recursive wildcard depending on the structure and rules you want.

For example:

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null;
}

Be careful with this kind of rule, though.

It can give access to much more data than you intended.

Do not add a broad wildcard just because it makes the error disappear.

Do not use `allow read, write: if true` as the final fix

You will sometimes see people recommend this while debugging:

allow read, write: if true;

Yes, it can make the permission error disappear.

It also allows anyone who can access your Firebase project from the client to read and write the matching data.

That is not a real fix.

If you temporarily use an open rule to confirm that the rules are the cause, put the secure rule back immediately afterward.

For example, if the app should only allow authenticated users:

allow read, write: if request.auth != null;

is very different from:

allow read, write: if true;

The goal is not simply to make Firebase stop complaining.

The goal is to make the rule match what your application is actually supposed to allow.

Check whether you are using the correct Firebase project

This one can waste a lot of time.

Your React Native app might be connected to a different Firebase project than the one you are looking at in the Firebase Console.

You think you are checking the rules for:

my-production-project

but the app is actually connected to:

my-development-project

Now you change rules in the console and nothing happens.

The app keeps returning:

permission-denied

because you are fixing the wrong project.

Check your Firebase configuration and make sure the project ID matches the Firebase project you are inspecting.

For Android, check the Firebase configuration used by your Android app.

For iOS, check the corresponding iOS Firebase configuration.

If you have development, staging, and production projects, this becomes especially important.

Check your Android and iOS Firebase configuration

If the problem only happens on one platform, compare the Firebase configuration between them.

For Android, make sure the correct Firebase configuration is being used.

For iOS, make sure the correct configuration is being used there as well.

A situation like this is possible:

Android → Firebase project A
iOS     → Firebase project B

You can then spend hours changing Firestore rules in project A while testing an iOS build that is actually talking to project B.

If the error happens only on Android or only on iOS, platform-specific Firebase configuration should be on your checklist.

Check Firebase App Check

App Check can also be involved when Firebase rejects requests.

App Check is designed to help verify that requests are coming from your legitimate app rather than an unauthorized client.

If you recently enabled App Check or changed its configuration, check whether the failing request is related to App Check.

This becomes especially important if:

the app worked before enabling App Check
requests work in one environment but not another
you are testing a development build
you changed App Check enforcement settings
you changed the app's Android or iOS configuration

Do not immediately disable App Check just because it is involved.

First determine whether the request is failing because of App Check configuration or because of your Firestore/Storage rules.

Those are different problems.

Development and production can behave differently

A common source of confusion is:

"It works in development, but my production build gets PERMISSION_DENIED."

That does not necessarily mean the Firebase rules randomly changed.

Your development and production builds may be using different:

Firebase projects
application IDs
bundle identifiers
configuration files
App Check settings
authentication settings
environment variables

If the problem only happens in a release build, compare the Firebase configuration between the working and failing builds.

This is usually more useful than changing your Firestore rules blindly.

Check the exact user ID being used

Suppose your rule is intended to allow users to access their own documents:

match /users/{userId} {
  allow read, write: if request.auth.uid == userId;
}

That means this request:

/users/123

will only work if:

request.auth.uid == "123"

If your application accidentally requests:

/users/456

while the logged-in user is actually 123, Firebase will reject it.

So log the values you are using while debugging:

console.log("Current user:", auth().currentUser?.uid);
console.log("Requested user:", userId);

If they do not match, you have found the problem.

This is much more useful than changing the security rule to allow everyone.

Check your Storage rules if the error happens during uploads

If the problem happens while uploading an image, PDF, or another file, you may actually be dealing with Firebase Storage rather than Firestore.

For example:

FirebaseError: [storage/unauthorized] User is not authorized to perform the desired action.

Storage has its own security rules.

A Firestore rule like:

allow read, write: if request.auth != null;

does not control Firebase Storage.

If the error happens during:

storage()
  .ref("profile-images/avatar.jpg")
  .putFile(filePath);

look at your Storage rules instead.

The service producing the error matters.

Check Realtime Database rules separately

The same idea applies to Realtime Database.

Realtime Database has its own rules structure, for example:

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

Changing Firestore rules will not fix a Realtime Database permission problem.

If your application uses several Firebase services, make sure you know which one is rejecting the request before changing anything.

Use the Firebase Emulator when appropriate

If you are working on complicated security rules, the Firebase Emulator Suite can make debugging much easier.

Instead of repeatedly testing rules against production data, you can test your rules locally.

This is especially useful when your rules depend on things like:

request.auth
request.auth.uid
request.resource.data
resource.data

For example, a rule might look correct at first glance but fail because the incoming document does not contain the field your rule expects.

Testing the rule with known authentication and data values makes these problems much easier to see.

Look at what changed right before the error

This is one of the most useful debugging habits for Firebase errors.

Ask:

What changed immediately before PERMISSION_DENIED appeared?

Maybe you:

changed Firestore rules
added authentication
changed the user document structure
switched Firebase projects
enabled App Check
changed an Android package name
changed an iOS bundle identifier
updated a Firebase dependency
moved a Firestore collection
changed the document ID
created a new production build

The timing does not prove what caused the error, but it gives you a very good place to start.

A simple debugging order

When I get a Firebase PERMISSION_DENIED error, I usually go through these checks:

1. Identify the Firebase service

Is it:

Firestore?
Storage?
Realtime Database?
App Check?
something else?

2. Read the exact path

What collection, document, or storage path is the app trying to access?

3. Check authentication

console.log(auth().currentUser?.uid);

Is there actually a logged-in user?

4. Check the security rule

Does the rule actually match the path being accessed?

5. Check the values used by the rule

If the rule compares user IDs, roles, or document fields, verify those values.

6. Check the Firebase project

Make sure the app and Firebase Console are using the same project.

7. Check App Check

Especially if the problem started after enabling or enforcing it.

8. Check platform-specific configuration

If only Android or iOS is affected, compare the configuration for that platform.

9. Reproduce the problem again

After making one change, test again.

This gives you a much clearer debugging trail.

Example: finding a simple rules mistake

Imagine your Firestore rule says:

match /users/{userId} {
  allow read: if request.auth != null
               && request.auth.uid == userId;
}

Your app is logged in as:

abc123

but your code requests:

/users/undefined

Firebase sees:

request.auth.uid == "abc123"

and:

userId == "undefined"

The condition is false.

So Firebase returns:

permission-denied

The problem is not Firebase.

The problem is that your application generated the wrong document path.

This is why checking the exact request is so important.

Final thoughts

PERMISSION_DENIED can be frustrating because the error itself is often very short while the number of possible causes is not.

The important thing is to avoid treating it as simply:

"Firebase permissions are broken."

Start by finding out which Firebase service rejected the request, then check the exact path, authentication state, security rules, and Firebase project.

If the error appeared after a recent change, use that as a clue.

And avoid the temptation to solve everything with:

allow read, write: if true;

That only hides the real problem and can leave your data exposed.

If your error is buried inside a much larger React Native/Firebase log and it is difficult to tell whether the problem is authentication, rules, App Check, configuration, or something else, you can paste the full error into FixMyError and use it to narrow down what is actually going wrong.

Try it at https://www.fixmyerrorapp.com.

Android System Back Button Closes the App After Upgrading to Target SDK 36 — React Native Fix

Tue, 22 Sep 2026 04:30:24 +0000

If you're maintaining a React Native Android application and recently upgraded your project to target SDK 36 (Android 16), you may encounter an unexpected navigation issue:

Pressing the Android system back button closes the app instead of navigating to the previous screen.

This can be particularly confusing when React Navigation is already configured correctly and the same navigation flow works perfectly on older Android target SDK versions.

This article explains what changed, how to identify the issue, the workaround I used, and what you should consider for a proper Android 16 migration.

The Problem

After upgrading the Android project from an older target SDK to:

targetSdkVersion = 36

the app started behaving differently when using the Android system back button.

For example, suppose the navigation stack is:

Home
  ↓
Products
  ↓
Product Details

When the user presses the Android system back button from Product Details, the expected behavior is:

Product Details
        ↓
    Products

Instead, the application could close.

Interestingly, navigation using React Navigation itself continued to work:

navigation.goBack();

The issue was specifically related to the Android system back event.

Environment

The issue was observed in a React Native application with a setup similar to:

React Native
React Navigation
Android SDK 36
Target SDK 36

The important change was upgrading the Android target SDK to API level 36, corresponding to Android 16.

Why Does This Happen?

The important part of the migration is the Android back-navigation change.

Android has been moving away from the older:

onBackPressed()

mechanism toward the newer:

OnBackInvokedDispatcher

and predictive back navigation APIs.

With newer Android versions and target SDK requirements, applications need to properly participate in the newer back-navigation system.

This can expose compatibility issues in applications or libraries that still rely on the older back handling mechanism.

In a React Native application, the Android system back event eventually needs to be correctly propagated into the React Native / React Navigation layer.

If that doesn't happen, Android may interpret the back action as:

No navigation handler
        ↓
Finish current Activity
        ↓
App closes

instead of:

System Back
     ↓
React Native Back Handler
     ↓
React Navigation
     ↓
Previous screen

How I Identified the Problem

The first thing I checked was whether React Navigation itself was working.

Navigation from the application was working correctly:

navigation.navigate("ProductDetails");

and programmatic back navigation also worked:

navigation.goBack();

The problem only occurred when pressing the physical/system Android back button.

I also checked whether the application was closing directly from the Home screen.

That behavior is expected:

Home
 ↓
Android Back
 ↓
App exits

The actual problem was:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
App exits ❌

instead of:

Home
 ↓
Product List
 ↓
Product Details
 ↓
Android Back
 ↓
Product List ✅

This distinction is important when debugging Android back navigation.

The AndroidManifest Configuration

The Android application can control the behavior of the newer back system using:

android:enableOnBackInvokedCallback

For example:

<application
    android:name=".MainApplication"
    android:label="@string/app_name"
    android:icon="@mipmap/ic_launcher"
    android:enableOnBackInvokedCallback="false">

In my case, setting:

android:enableOnBackInvokedCallback="false"

worked as a temporary workaround.

After adding this configuration, the Android system back button once again started navigating to the previous React Navigation screen instead of immediately closing the application.

Why Does `false` Work?

Setting:

android:enableOnBackInvokedCallback="false"

essentially disables the application's participation in the newer OnBackInvokedDispatcher behavior.

This allows the application to continue using the older back handling path.

Conceptually:

Without the workaround

Android System Back
        ↓
OnBackInvokedDispatcher
        ↓
React Native / Navigation handler
        ↓
❌ Handler not properly triggered
        ↓
Activity finishes
        ↓
App closes

With the temporary workaround

Android System Back
        ↓
Legacy back handling
        ↓
React Native BackHandler
        ↓
React Navigation
        ↓
Previous screen

So the workaround doesn't really "fix" predictive back support.

It tells Android to avoid the newer callback behavior for this application.

Is `enableOnBackInvokedCallback="false"` the Permanent Fix?

Not necessarily.

This is an important distinction.

If your application is targeting Android 16, you should ideally investigate whether your React Native version and navigation dependencies properly support Android's newer back-navigation behavior.

Using:

android:enableOnBackInvokedCallback="false"

can be useful as a compatibility workaround while migrating, but it should not automatically be considered the final Android 16 solution.

The long-term goal should be:

Android 16
      ↓
Predictive Back
      ↓
OnBackInvokedDispatcher
      ↓
React Native
      ↓
React Navigation

working correctly.

Check Your React Native Version

Before adding application-level workarounds, check the React Native version:

npm list react-native

or:

yarn why react-native

Also check React Navigation:

npm list @react-navigation/native

For example:

react-native
@react-navigation/native
@react-navigation/native-stack
@react-navigation/bottom-tabs

Older combinations may have different levels of Android predictive-back support.

It's important to evaluate the complete dependency chain rather than changing only the AndroidManifest.

Check Your `MainActivity`

Also inspect your Android MainActivity.

A typical React Native application may have something similar to:

public class MainActivity extends ReactActivity {

    @Override
    protected String getMainComponentName() {
        return "MyApp";
    }
}

If your application has custom back handling, search the Android project for:

onBackPressed

For example:

grep -R "onBackPressed" android/

Also search for:

OnBackInvokedDispatcher

and:

OnBackInvokedCallback

This helps identify whether custom native code is interfering with the new Android back-navigation mechanism.

Check React Native `BackHandler`

React Native applications can listen for Android back events using:

import { BackHandler } from "react-native";

For example:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      navigation.goBack();
      return true;
    }
  );

  return () => subscription.remove();
}, [navigation]);

However, don't add this globally just to hide the problem.

React Navigation normally handles Android back navigation for its navigation stack.

Adding multiple global BackHandler listeners can introduce new problems such as:

Back event being consumed too early
Incorrect navigation
Screens being popped multiple times
Modals not closing correctly
Navigation stack becoming inconsistent

So first determine whether the underlying Android back event is reaching React Native correctly.

A Useful Debugging Test

You can temporarily add a BackHandler listener to determine whether React Native receives the system back event:

useEffect(() => {
  const subscription = BackHandler.addEventListener(
    "hardwareBackPress",
    () => {
      console.log("ANDROID BACK EVENT RECEIVED");

      return false;
    }
  );

  return () => subscription.remove();
}, []);

Then navigate to a screen and press the Android system back button.

If you see:

ANDROID BACK EVENT RECEIVED

then the event is reaching React Native.

If the app closes without the event reaching your JavaScript handler, the problem is likely further down in the Android back-dispatching path.

This is a useful way to separate:

Android back event problem

from:

React Navigation configuration problem

Don't Confuse Home Screen Behavior With a Bug

One important testing detail:

If the user is already on the root screen:

Home

pressing Android Back is normally expected to exit the application.

For example:

Home
 ↓
Android Back
 ↓
App closes

That alone isn't evidence of a problem.

The important test is:

Home
 ↓
Screen A
 ↓
Screen B
 ↓
Android Back

Expected:

Screen B
 ↓
Screen A

If instead:

Screen B
 ↓
App closes

then back navigation is not being handled correctly.

Testing Checklist After Target SDK 36 Upgrade

After upgrading to API 36, I recommend testing all of these scenarios.

Home → List → Details

Press system Back.

Expected:

Details → List

Home → A → B → C

Press Back repeatedly.

Expected:

C → B → A → Home

3. Root screen

Home

Press Back.

Expected:

App exits

Open a modal and press Back.

Expected:

Modal closes

instead of:

App exits

5. Bottom tabs

Test:

Tab A → Tab B → Screen

and verify that system Back behaves consistently with your navigation design.

6. Authentication flow

Test:

Login → OTP → Home

and make sure Back doesn't allow users to incorrectly return to authentication screens.

7. Deep links

Test:

Deep Link → Details

and verify the back stack behaves as expected.

Test using:

3-button navigation
Gesture navigation

Predictive back behavior can differ from traditional button-based testing, so both should be tested.

Temporary Workaround

If your application is currently affected and you need to stabilize the release, one possible temporary configuration is:

<application
    ...
    android:enableOnBackInvokedCallback="false">

After rebuilding the application:

cd android
./gradlew clean
cd ..

Then rebuild:

npx react-native run-android

or use your normal release build process.

For an Expo bare/prebuild project, make sure the generated Android configuration is also correctly reflected in the source configuration you use for builds, rather than relying on a manual change that can be overwritten.

Recommended Migration Approach

Instead of treating the manifest flag as the final solution, I recommend approaching the migration in this order:

1. Upgrade target SDK → 36
          ↓
2. Test system Back
          ↓
3. Check React Native version
          ↓
4. Check React Navigation versions
          ↓
5. Search for custom Android back handling
          ↓
6. Search for BackHandler overrides
          ↓
7. Test predictive back
          ↓
8. Update incompatible dependencies
          ↓
9. Use manifest workaround if required
          ↓
10. Remove workaround after proper migration

This approach makes it easier to identify the actual compatibility problem.

Important Takeaway

Upgrading:

targetSdkVersion

is not always just a build configuration change.

A target SDK upgrade can activate or expose new Android platform behavior.

For Android 16 / API 36, back navigation and predictive back behavior are especially important areas to test.

If your React Native app suddenly starts closing when the Android system back button is pressed after moving to target SDK 36, don't immediately assume that your React Navigation stack is broken.

First determine whether:

Android
   ↓
Back Dispatcher
   ↓
React Native
   ↓
React Navigation

is working correctly.

The following configuration can serve as a temporary compatibility workaround:

android:enableOnBackInvokedCallback="false"

but the preferred long-term solution is to ensure that the React Native and navigation stack properly supports Android's modern back-navigation APIs.

Final Checklist

Before releasing a target SDK 36 build, verify:

[ ] Android system Back navigates correctly
[ ] Root screen exits correctly
[ ] Nested navigation works
[ ] Modals handle Back correctly
[ ] Bottom tabs behave correctly
[ ] Authentication screens behave correctly
[ ] Deep links create the expected back stack
[ ] Gesture navigation works
[ ] 3-button navigation works
[ ] Predictive back behavior has been tested
[ ] React Native version is compatible
[ ] React Navigation dependencies are compatible
[ ] Custom BackHandler logic has been reviewed
[ ] Native onBackPressed() implementations have been reviewed
[ ] OnBackInvokedDispatcher usage has been reviewed
[ ] Any temporary enableOnBackInvokedCallback workaround is documented

Conclusion

Android 16 introduces another step in the evolution of Android back navigation. For React Native applications, upgrading to target SDK 36 can expose problems where the system Back button no longer reaches the JavaScript navigation layer as expected.

If your app starts closing instead of navigating backward, investigate the new Android back-dispatching behavior before modifying your navigation stack.

A manifest-level workaround such as:

android:enableOnBackInvokedCallback="false"

may restore the previous behavior temporarily, but dependency compatibility and proper predictive-back support should be addressed as part of the complete migration.

Target SDK upgrades should always be followed by dedicated navigation regression testing—not just build and installation testing.

✍️ Written by Dainy Jose — React Native Mobile Application Developer with 3+ years of experience building cross-platform mobile apps using React Native (Expo, TypeScript, Redux).
Currently expanding backend knowledge through the MERN Stack (MongoDB, Express.js, React.js, Node.js) to create more efficient, full-stack mobile experiences.

Tech Stack: React Native · TypeScript · Redux · Expo · Firebase · Node.js · Express.js · MongoDB · REST API · JWT · Jest · Google Maps · Razorpay · PayU · Agile · SDLC · Git · Bitbucket · Jira

Connect with me:
Portfolio
LinkedIn
GitHub

The Firebase Auth bug that took me 3 days to find (it wasn't Firebase's fault)

Sat, 19 Sep 2026 08:24:54 +0000

The symptom

signInWithRedirect would fire fine — the Google popup flow completed, the redirect came back, and then... nothing. auth.currentUser was null. No error in the console. No failed network request. The user object had just vanished somewhere between the redirect and my app reading it.

The frustrating part: it worked perfectly on localhost. It only broke in production.

The wrong turns

First guess: async timing bug. I wrapped the auth-state check in every useEffect variation I could think of, added loading states, tried onAuthStateChanged instead of reading currentUser directly. No change.

Second guess: a config mismatch. I diffed my Firebase config between local and prod character by character. Identical.

Third guess: CORS. Checked network tab, no CORS errors, no failed requests at all — which in hindsight should have been the clue. A CORS problem fails loudly. This was failing silently.

What was actually happening

Firebase's redirect-based auth flow works by briefly using an iframe on your authDomain (typically your-project.firebaseapp.com) to relay the session back to your app. That relay depends on third-party storage being accessible inside that iframe — cookies/localStorage set on firebaseapp.com, read while your actual site is on a different domain.

Browsers have been steadily tightening third-party storage partitioning (Safari's been strict about this for years, Chrome's been catching up). Production was on my real custom domain. Local dev was hitting localhost, which a lot of browsers still treat more permissively. That's why it "worked" locally and silently died in prod — the iframe's storage access was just being partitioned away, and Firebase had no clean way to surface that as an error since, from its perspective, the browser just... didn't return anything.

The fix

Switch to signInWithPopup instead of signInWithRedirect. Popup-based auth doesn't rely on that same cross-domain iframe storage relay — the popup and the opener communicate directly, sidestepping the whole partitioning problem.

// Before: silently broke in production
await signInWithRedirect(auth, provider);

// After: works consistently across browsers
await signInWithPopup(auth, provider);

Trade-off: popups get blocked more aggressively on mobile and by some ad blockers, so it's not a strictly-better default — just a better fit for what was actually failing here.

The lesson

When something works locally and silently fails in production with zero error output, my new first suspect is cross-origin storage behavior, not application logic. Silent failure is often the browser deciding not to tell you it blocked something, rather than your code doing something wrong.

Anyone else hit this exact wall with Firebase (or any auth provider using a similar iframe-relay pattern)? Curious if others landed on popup, or found a way to keep redirect working reliably.

The Trigger Swap That Broke Every Downstream Reference

Tue, 15 Sep 2026 13:15:42 +0000

I built this workflow — a lead intake automation for a made-up client, Ferrer Window Co. — with a Form Trigger first, even though I knew from the start it needed to end up on a Webhook. That wasn't the plan drifting. It was deliberate: I'd used webhooks before and Form Trigger less, so building with Form Trigger first let me see real data coming through without also holding webhook payload structure in my head at the same time. Get the logic right, then swap the trigger once everything else was solid.

And the logic did get solid. By the time I was ready to swap, I had a full chain working: an IF node filtering out junk leads (both phone and email empty), a Set node defaulting empty message fields to "No message provided," and Sheets and Slack both branching off that same cleaned data independently. Tested both edge cases — junk lead correctly stopped, empty message correctly defaulted. Everything passed.

Then I deleted the Form Trigger, added a Webhook node, and sent a test payload through Postman.

It broke immediately.

Not the logic — the logic was fine. What broke was every single reference to the data. With Form Trigger, the payload had come through flat:

{
  "Name": "Tarek",
  "Phone": "02-011-41104-582",
  "Email": "*Emails are not allowed*",
  "Service address": "Primary school st",
  "Message": "I want to request an order",
  "submittedAt": "2026-08-24T03:24:50.089-04:00",
  "formMode": "test"
}

With Webhook, everything I actually wanted was nested one level down, sitting alongside a pile of raw HTTP metadata I didn't need:

{
  "headers": {...},
  "body": {
    "Name": "Tarek",
    "Phone": "02-011-41104-582",
    ...
  },
  "webhookUrl": "...",
  "executionMode": "test"
}

Every reference I'd written — the IF node's condition, the Set node's field mappings — pointed at $json.Name, $json.Phone, and so on. None of it was wrong, exactly. It was just pointed at a shape of data that no longer existed. The whole workflow's reasoning was intact and now unreachable.

So I went back through it node by node — the IF node's conditions, the Set node's mappings — and repointed every one from $json.X to $json.body.X. Nothing about what the workflow decided changed. Only where it looked for the thing it was deciding about.

Once that was done, I didn't just assume it worked because the references compiled. I re-ran both edge cases through the webhook path — both phone and email empty, and an empty message field — to confirm the filter still stopped junk leads and the default still kicked in, now that the data was arriving through a different shape entirely.

The part I'd flag for anyone doing this same swap later: it's not a dramatic failure. Nothing throws a loud error that points you at the fix. The workflow just quietly stops seeing the data it expects, because the trigger node changed the shape of what "the data" even means. If you built your logic against one trigger's payload structure, swapping the trigger isn't a drop-in replacement — it's a second pass through everything downstream, checking what each node thinks it's looking at.

How to Fix Expo Doctor Errors in Expo

Mon, 07 Sep 2026 11:14:51 +0000

If you work with Expo long enough, you will probably run into expo-doctor.

You run:

npx expo-doctor

and instead of everything being green, you get something like:

✖ Check Expo config
✖ Check dependencies
✖ Check package versions

Sometimes there is one problem.

Sometimes there are several.

And sometimes the output looks much worse than the actual problem.

The good thing is that expo-doctor is usually pretty clear about what it does not like. The tricky part is knowing what the warnings actually mean and which ones you need to fix.

Here is how I usually work through Expo Doctor errors without immediately changing half of the project.

First, run Expo Doctor by itself

Start with:

npx expo-doctor

Let it finish and read the full output.

Do not immediately start changing dependencies just because you see a red ✖.

Expo Doctor runs several checks, and a failure in one check does not necessarily mean your entire project is broken.

For example, you might see:

✖ Check that packages match versions required by installed Expo SDK

That is very different from:

✖ Check for common project configuration problems

The first one points toward dependency versions.

The second could require looking at your Expo configuration.

So the first step is simply figuring out which check actually failed.

Check your Expo SDK version

A lot of Expo Doctor problems come down to package versions not matching the Expo SDK you are using.

You can check your Expo version in package.json:

{
  "dependencies": {
    "expo": "~54.0.0"
  }
}

The exact version will depend on your project.

You can also run:

npx expo --version

and:

npx expo config --type public

The important thing is to know which Expo SDK your project is actually using before changing dependencies.

This matters because Expo packages are not completely independent of the SDK.

You cannot always just install the newest version of every package and expect everything to work together.

Fix packages that are on the wrong version

One of the most common Expo Doctor messages is related to package versions.

For example:

✖ Check that packages match versions required by installed Expo SDK

Expo may tell you that some packages are expected to be on different versions.

If that happens, do not manually guess which version to install.

For Expo-managed projects, use:

npx expo install

Expo can use your current SDK to install compatible package versions.

You can also check the project with:

npx expo install --check

If it reports packages that are out of date, you can usually let Expo correct them with:

npx expo install --fix

This is generally safer than doing something like:

npm install package-name@latest

because the latest package version is not necessarily the version your current Expo SDK expects.

Do not blindly update everything

This is worth mentioning because it is an easy mistake to make.

Suppose Expo Doctor tells you that three packages have version mismatches.

You might think:

Fine, I'll just update everything.

Then you run something like:

npm update

and suddenly you have five new errors.

You have now changed many things at once, which makes it harder to figure out what actually caused the problem.

If Expo is telling you that a package should be on a specific version, start with that package.

For example:

npx expo install react-native-screens

rather than manually searching for the newest version and installing it.

Make one meaningful change at a time when possible.

It makes debugging much easier.

Check `package.json` for old dependencies

Another common situation is an old dependency that you no longer use.

Over time, a project can collect packages from old features, experiments, tutorials, or libraries you tried and later removed.

Your package.json might contain:

{
  "dependencies": {
    "some-old-package": "^1.2.3"
  }
}

even though nothing in your application imports it anymore.

If Expo Doctor complains about that package, first check whether you still need it.

Search your project for:

some-old-package

If there are no imports or references and you know you do not need it anymore, removing the dependency may be the correct fix.

For npm:

npm uninstall some-old-package

For Yarn:

yarn remove some-old-package

Then run Expo Doctor again.

Check for packages that are not compatible with your project

Sometimes the problem is not simply that a package is old.

A package may require native code or a setup that does not fit the way your Expo project is configured.

This becomes especially important when adding React Native libraries that were designed with bare React Native projects in mind.

You may install a package successfully with npm, but that does not automatically mean your Expo project is configured to use it correctly.

If Expo Doctor starts complaining immediately after adding a new library, that timing is useful information.

Try to remember:

What changed right before the error appeared?

If you just installed a package and Expo Doctor started failing, investigate that package first.

Check your Expo configuration

Expo Doctor can also complain about your project configuration.

Depending on your setup, this information may live in:

app.json

or:

app.config.js

or:

app.config.ts

For example, your configuration might contain something like:

{
  "expo": {
    "name": "My App",
    "slug": "my-app"
  }
}

If you recently changed your configuration, added a plugin, changed an Android or iOS setting, or installed a package that requires an Expo config plugin, check those changes carefully.

A configuration problem can sometimes look like a dependency problem because several parts of the Expo toolchain depend on the same project configuration.

Check Expo config plugins

Config plugins are another area that can cause confusion.

If you have something like:

{
  "expo": {
    "plugins": [
      "some-package"
    ]
  }
}

make sure that package is actually installed and that the plugin is valid for your current setup.

A common situation is:

You install a package.
You add its plugin to the Expo configuration.
Later, you remove the package.
The plugin entry stays behind.

Now Expo may still try to process something that no longer exists.

If you recently removed a native package, check app.json or your app config for leftover plugin entries.

Check for duplicate dependencies

Another useful thing to investigate is duplicate versions of the same package.

For example, your project might end up with different parts of the dependency tree using different versions of a React Native package.

You can inspect the dependency tree with npm:

npm ls

Or check a specific package:

npm ls react-native-screens

If you see multiple versions where you expected one, that can be a clue.

This does not automatically mean that multiple versions are wrong. Some projects legitimately have them.

The important part is to understand why they are there before trying to force everything onto one version.

Check your React Native version too

Expo SDK and React Native versions are closely related.

If you manually changed your React Native version, or upgraded one without properly upgrading the Expo SDK around it, Expo Doctor may start reporting compatibility problems.

For example, if your package.json contains:

{
  "dependencies": {
    "expo": "~54.0.0",
    "react-native": "..."
  }
}

make sure those versions belong together.

If you are upgrading Expo, follow the Expo upgrade process instead of manually changing a bunch of package versions and hoping they line up afterward.

A partially upgraded project is often harder to fix than a project that was left alone.

Run `expo-doctor` again after fixing something

This sounds obvious, but it is an important part of the process.

After making a change, run:

npx expo-doctor

again.

You want to know whether the change actually fixed the problem.

For example:

Before:
✖ Check package versions

After:
✔ Check package versions

Now you know that particular problem is gone.

If another check is still failing, you can work on that one separately.

This is much easier than making ten changes and running Expo Doctor once at the end.

What if Expo Doctor still fails?

If you have corrected the obvious dependency and configuration problems but Expo Doctor is still reporting an error, look at the exact check that is failing.

For example:

✖ Check for common project configuration problems

is not enough information by itself.

Read the lines underneath it.

Expo Doctor normally provides additional information about what it found.

That information is much more useful than the ✖ itself.

Copy the complete section of the output, not just the first line.

Clear the cache if the project still behaves strangely

Clearing caches is not usually the first fix for an Expo Doctor warning.

Expo Doctor is checking your project configuration and dependencies, so a cache reset will not magically fix an incorrect package version.

However, if you have already fixed the reported problem and the project is still behaving as if the old state exists, clearing the Metro cache can help.

For Expo:

npx expo start -c

This is particularly useful after changing dependencies, imports, or other files that Metro may have cached.

Just keep in mind that clearing Metro's cache and fixing Expo Doctor are two different things.

When reinstalling `node_modules` makes sense

If your package configuration looks correct but your installation itself seems broken, reinstalling dependencies can be worth trying.

Delete:

node_modules

Then reinstall:

npm install

Afterward:

npx expo-doctor

And if necessary:

npx expo start -c

I would not delete your lockfile automatically.

Your package-lock.json or yarn.lock records the dependency versions that your project is using. Removing it can cause a completely new dependency tree to be installed, which may introduce more changes than you wanted.

If you specifically need to regenerate the lockfile, that is a different situation.

Be careful when upgrading an Expo project

If the reason for your Expo Doctor errors is that you are trying to move to a newer Expo SDK, do not treat it like a normal dependency update.

An Expo SDK upgrade can involve:

Expo packages
React Native
React
native dependencies
config plugins
Android configuration
iOS configuration
other packages tied to the SDK

If you upgrade only one or two pieces, you can end up with a project where everything is technically installed but the versions do not belong together.

If your goal is specifically to upgrade Expo, follow the upgrade process for the target SDK rather than trying to fix every warning individually.

A simple way to approach Expo Doctor

When I get an Expo Doctor error, I usually work through it in this order:

1. Run Expo Doctor

npx expo-doctor

2. Find the failed check

Do not worry about every line yet. Find the actual ✖ checks.

3. Read the details underneath

That is usually where the useful information is.

4. Check what changed recently

Did you:

install a package?
update Expo?
update React Native?
remove a package?
change app.json?
add a config plugin?
switch branches?

Recent changes are often the best clue.

5. Fix the smallest thing first

If a package version is wrong, fix that package.

If a plugin is left behind, remove it.

If a dependency is no longer needed, uninstall it.

6. Run Expo Doctor again

npx expo-doctor

Then see what remains.

This gives you a much cleaner debugging loop.

One example

Imagine you run:

npx expo-doctor

and get a dependency version warning.

You check package.json and notice that you manually installed a newer version of an Expo-related package a few days ago.

Instead of immediately reinstalling everything, you can try:

npx expo install

or, if Expo identifies the package as needing a correction:

npx expo install --fix

Then run:

npx expo-doctor

again.

If the check passes, you have your answer.

If it does not, you now have a smaller problem to investigate.

That is the part that makes debugging much easier: change something, test it, and use the new output to decide what to do next.

Final thoughts

Expo Doctor is there to help you find problems before they turn into much bigger issues.

The important thing is not to treat every warning as a reason to rebuild your entire project.

Start with the exact check that failed.

If it is a dependency problem, check the package versions.

If it is a configuration problem, check your Expo config.

If you recently installed or removed a package, investigate that change.

And if you are upgrading Expo, make sure you are upgrading the related dependencies together instead of manually mixing versions.

Most importantly, avoid making a dozen changes at once. When you do that, even if the error disappears, you have no idea which change actually fixed it.

If your Expo Doctor output is more complicated—especially when several checks fail at the same time—you can paste the full error into FixMyError and use it to break down what the output is actually telling you.

You can try it at https://www.fixmyerrorapp.com.

The Single Variable Rule Is As True In Debugging As It Is In A Lab

Thu, 03 Sep 2026 14:14:20 +0000

Most of us here debug for a living, and the habit that has helped me the most did not come out of software at all, it came out of lab method. The overlap is closer than it looks, so it seemed worth writing up for this crowd.

Change One Thing, Then Look

When a bug will not reproduce, the instinct is to bump the dependency, tweak the config, and add a retry, all in one pass. If it starts working after that, you have not fixed anything, you have hidden it. You now have four candidate causes and no way to tell them apart.

Lab work has the same rule and states it more bluntly: change one variable per run. If you alter the concentration and the temperature and the container at the same time, the result cannot tell you which change mattered. Software gives us the illusion that we can skip this because iteration is cheap, but the reasoning cost is identical.

Write Down The Raw Numbers, Not The Conclusion

The other borrowed habit is the notebook. Not a summary written after the fact, the actual numbers: input, timestamp, the exact command, what came back. The value shows up on run four, when a pattern appears that no single run would have revealed.

This is exactly the discipline that setting up a home lab forces on you, because there is no log aggregator to fall back on. Date, question, materials with quantities, procedure, raw results, and what surprised you. Six lines. Anyone who has tried to reconstruct a debugging session from memory a week later already knows why it matters.

Reproduce Three Times Before You Believe It

One passing run is not a fix, it is a data point. Race conditions, cache warmth, and machine state all produce green on the first try. Three clean runs, ideally on a cold start, is the cheapest form of replication available to us and it catches the fixes that were never fixes.

None of this is new, it is just the scientific method with different tooling. The parts we tend to drop are the boring ones: one change at a time, raw records, and repeat before believing. Those three are what make debugging cumulative instead of a loop.

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

Fri, 28 Aug 2026 13:36:15 +0000

How to Fix “Unable to Resolve Module” Errors in React Native and Expo

If you have been working with React Native or Expo for a while, there is a good chance you have seen an error that looks something like this:

Unable to resolve module ./components/Header from App.js

None of these files exist:
  * components/Header(.native|.ios|.android|.js|.jsx|.ts|.tsx)
  * components/Header/index(.native|.ios|.android|.js|.jsx|.ts|.tsx)

Or maybe:

Unable to resolve module react-native-safe-area-context from App.js

Or the error is buried somewhere inside a much larger Metro bundler log, making it harder to see what is actually wrong.

The annoying part about this error is that "Unable to resolve module" does not always mean the same thing.

Sometimes the file path is wrong. Sometimes the package was never installed. Sometimes it is installed, but your dependencies are in a bad state. And sometimes everything looks correct until you notice that one letter in a filename has the wrong capitalization.

I've run into all of these before.

So instead of randomly deleting node_modules and hoping for the best, here is how I usually work through this error.

First, read the exact module Metro cannot find

This sounds obvious, but the first line of the error usually tells you exactly what Metro is looking for.

For example:

Unable to resolve module ./components/Header from App.js

Metro is trying to find:

./components/Header

relative to:

App.js

That immediately gives you something to check.

Ask yourself:

Does that file actually exist?
Is the path correct?
Is the filename spelled correctly?
Are you importing it from the correct folder?

For example, imagine your project looks like this:

my-app/
├── App.js
└── components/
    └── Header.js

Then this import should work:

import Header from "./components/Header";

But this will not:

import Header from "./component/Header";

One missing s is enough to break the build.

When the error points to a local file, I usually start here before doing anything else.

Check the file name and capitalization

This one can be surprisingly annoying, especially if your app worked on one machine but suddenly fails during a build or after pushing the project somewhere else.

Imagine your file is named:

header.js

But your import says:

import Header from "./components/Header";

Depending on the operating system and environment, this can cause problems because:

header.js

and:

Header.js

are not always treated as the same file.

The same thing can happen with folders:

Components/

vs:

components/

If Metro says it cannot find a local module and the path looks correct at first glance, check every part of the path carefully.

I have lost more time than I would like to admit because of a single capital letter.

Make sure the package is actually installed

Sometimes the missing module is not one of your own files.

For example:

Unable to resolve module react-native-safe-area-context

In that case, check whether the package exists in your project.

You can look inside package.json and see whether it is listed under dependencies.

For an Expo project, it is usually better to install Expo-compatible packages with:

npx expo install react-native-safe-area-context

For a regular React Native project, you would normally use:

npm install react-native-safe-area-context

or:

yarn add react-native-safe-area-context

The exact command depends on your project, but the important part is this:

Do not assume a package is installed just because you used it in your code.

It is also possible that you copied code from another project, tutorial, or GitHub repository without installing all of the required dependencies.

Check if the package name is correct

Another simple but common problem is importing the wrong package name.

For example, you might write something like:

import Something from "react-native-something";

but the actual package name could be slightly different.

Before reinstalling everything, check:

The package name in your import.
The package name in package.json.
The package name from the package documentation.

One small typo can produce the same "Unable to resolve module" error as a completely missing dependency.

Reset the Metro cache

If the file or package exists and the import looks correct, the next thing I would try is clearing Metro's cache.

For Expo:

npx expo start -c

For React Native, you can try:

npx react-native start --reset-cache

Metro caches information to make development faster, but occasionally the cache gets in the way after things change.

For example, you might have:

renamed a file,
moved a folder,
installed a new package,
changed an import,
switched branches in Git.

If the project is still behaving like the old version exists, clearing the cache is a quick thing to try.

I would not start by deleting half the project, though. Resetting the cache is much less destructive.

Check your `node_modules`

Sometimes the dependency is listed in package.json, but something went wrong during installation.

This can happen after:

switching branches,
changing package versions,
interrupting an installation,
moving the project to another computer,
or getting dependency conflicts.

A common approach is to reinstall your dependencies.

First, remove node_modules.

Then run:

npm install

Or, if you use Yarn:

yarn install

After that, start the project again and clear Metro's cache.

For Expo, that could look like:

npx expo start -c

Try to use the same package manager consistently. If your project uses package-lock.json, randomly switching between npm, Yarn, and other package managers can create confusing dependency problems.

Check whether you are importing from the correct location

This is especially easy to miss after moving files around.

Imagine you originally had:

src/
├── screens/
│   └── HomeScreen.js
└── components/
    └── Header.js

Inside HomeScreen.js, you might import:

import Header from "../components/Header";

Then later, you move HomeScreen.js somewhere else:

src/
├── app/
│   └── screens/
│       └── HomeScreen.js
└── components/
    └── Header.js

The old import path may no longer be correct.

You would need to update it accordingly:

import Header from "../../components/Header";

When you see an "Unable to resolve module" error after reorganizing your project, check whether the import path still matches the new folder structure.

Be careful with relative paths

Relative imports can become difficult to read when your project grows.

You might end up with something like:

import Something from "../../../../components/Something";

At that point, it becomes much easier to accidentally use one ../ too many or too few.

If the error points to a long relative path, carefully trace it from the file where the import is written.

For example:

import Header from "../../../components/Header";

Do not just count the dots and slashes quickly. Actually check the location of the current file and follow the path step by step.

It is boring, but it is often faster than trying random fixes.

Check whether the package is compatible with Expo

This is more important if you are using Expo.

You may find a React Native package online, install it successfully, and then run into problems because the version does not match your Expo SDK or the package needs native setup that your project does not currently support.

When possible, use:

npx expo install package-name

instead of blindly installing the latest version with npm.

Expo can choose a version that is compatible with your current SDK.

You can also run:

npx expo-doctor

to check your project for dependency and configuration issues.

If Metro suddenly cannot resolve something after installing or updating a package, compatibility is worth checking.

Watch out for renamed or removed files

Another situation that can cause this error is when your code still imports something that no longer exists.

For example, you rename:

OldButton.js

to:

CustomButton.js

but somewhere in the project, you still have:

import OldButton from "./OldButton";

The error might not happen immediately if that file is not loaded until you visit a specific screen.

This is why I would search the project for the old filename.

Your editor's global search is useful here. Search for:

OldButton

and see whether any old imports are still left behind.

Check `index` files

Sometimes the missing module is actually caused by an index.js or index.ts file.

For example:

components/
├── Button/
│   ├── Button.js
│   └── index.js

You might import it like this:

import Button from "./components/Button";

That usually depends on Metro being able to resolve the folder's index file correctly.

If index.js was deleted, renamed, or contains a broken export, your import setup may stop working.

Check whether the folder contains the file Metro expects.

For example:

export { default } from "./Button";

Or:

export { Button } from "./Button";

The correct setup depends on whether you are using default or named exports.

The important part is to check the whole import chain, not just the first file.

Default exports and named exports are a different problem, but still worth checking

This usually causes a different error, but it can easily appear around the same time.

For example, this is a default export:

export default Header;

And it is imported like this:

import Header from "./Header";

A named export looks like this:

export const Header = () => {
  return null;
};

And it should be imported like this:

import { Header } from "./Header";

If you have already fixed the module resolution error but the app still fails afterward, this is one of the next things I would check.

Sometimes you fix one problem and Metro finally gets far enough to show you the next one.

That is just part of debugging.

Monorepos can make module resolution more complicated

If you are using a monorepo, workspaces, shared packages, or code outside the main app folder, Metro module resolution can become more complicated.

Your project might look something like this:

my-project/
├── apps/
│   └── mobile/
└── packages/
    └── shared/

Then the React Native or Expo app might need to import code from:

packages/shared

In these cases, a normal relative import may not be enough. Metro may need additional configuration to watch or resolve files outside the main project directory.

If you only started seeing the error after introducing a workspace or shared package, I would focus on your Metro configuration instead of repeatedly reinstalling dependencies.

Monorepo issues usually need a more specific fix because the correct setup depends heavily on how the project is structured.

If you use Expo Router, check your imports and project structure

Expo Router adds another layer to how files are organized.

For example, your routes may live inside:

app/

and you may have layouts, route groups, and nested folders.

If you recently moved or renamed route files, double-check your imports and references.

Also make sure the required Expo Router packages are correctly installed for your current Expo setup.

When something goes wrong inside a routing setup, the error message may make it look like a general Metro problem when the real issue is simply an incorrect import somewhere inside a route or layout.

Again, start with the exact module Metro says it cannot find.

Do not immediately delete everything

When developers hit a module resolution error, a common reaction is to do all of this at once:

Delete node_modules
Delete package-lock.json
Clear Metro
Clear npm cache
Reinstall everything
Restart the computer

Sometimes that works.

But it can also make debugging harder because now you have changed five different things and do not know what actually fixed the problem.

I would usually check the error in this order:

Read the exact missing module.
Check whether the file or package exists.
Check the spelling and capitalization.
Check the import path.
Check whether the dependency is installed.
Clear the Metro cache.
Reinstall dependencies if necessary.
Check Expo or React Native version compatibility.
Investigate Metro configuration for more complex project setups.

This is usually much faster than throwing random commands at the project.

A quick example

Imagine you get this error:

Unable to resolve module ./components/ProfileCard from App.js

You check your project and see:

components/
└── Profilecard.js

The problem is the capitalization.

Your import says:

import ProfileCard from "./components/ProfileCard";

But the actual file is:

Profilecard.js

Rename the file so it matches:

ProfileCard.js

Then restart Metro if necessary:

npx expo start -c

That is a simple example, but it shows why reading the exact error matters.

The error is not always asking you to reinstall your entire project. Sometimes Metro is simply telling you that it cannot find something because the path does not exactly match what exists on disk.

Final thoughts

"Unable to resolve module" errors can look more serious than they really are.

Most of the time, the problem comes down to one of these things:

A wrong import path
A missing package
A typo in the package name
A filename capitalization problem
A stale Metro cache
Broken or missing dependencies
A file that was moved or renamed
A more complex Metro configuration issue

The biggest thing I have learned is to start with the exact module Metro says it cannot find.

Do not start by reinstalling the entire project.

Check what Metro is looking for, where it is looking from, and whether that file or package actually exists. In many cases, the answer is much simpler than the size of the error message makes it seem.

If your error is much messier than this—especially if the missing module is buried inside a large Expo, Metro, dependency, or build error—you can also paste the full error into FixMyError and get help breaking down what is actually causing it.

Sometimes the hard part is not finding a fix. It is figuring out which part of a long error log actually matters.

Try it here: https://www.fixmyerrorapp.com

Common CSS Mistakes Beginners Make (and How to Fix Them)

Tue, 25 Aug 2026 05:00:00 +0000

Introduction

Every one of these mistakes cost me real debugging time when I was learning. Not because CSS is inherently confusing — but because nobody explained why these things happen, just that they do. Understanding the "why" is what actually prevents you from repeating them.

1. The Box Model Confusion

By default, width and height don't include padding and border — meaning a box you set to 300px wide can visually render wider once padding is added.

.box {
  width: 300px;
  padding: 20px;
  border: 2px solid black;
  /* Actual rendered width: 300 + 20+20 + 2+2 = 344px */
}

The fix: set this once, globally, at the start of every project:

* {
  box-sizing: border-box;
}

Now width: 300px means the element is always 300px total, padding and border included. This single line prevents a huge number of layout bugs.

2. Margin Collapse

Two vertical margins between sibling elements don't add together — they collapse into the larger of the two.

.first { margin-bottom: 20px; }
.second { margin-top: 30px; }
/* Actual gap between them: 30px, NOT 50px */

This confuses beginners constantly because it seems inconsistent — but it's expected browser behavior for vertical margins specifically (doesn't apply to horizontal margins, or to Flexbox/Grid gap).

The fix: use gap on a flex or grid container instead of relying on margins between children — it doesn't collapse and is far more predictable.

3. Overusing `!important`

.button {
  background: blue !important;
}

!important overrides normal CSS specificity rules — which feels like a quick fix, but it creates a mess later. Once you have several !important rules fighting each other, debugging becomes genuinely painful because normal specificity logic no longer applies.

The fix: understand specificity instead. IDs beat classes, classes beat elements. If you're reaching for !important, it usually means a more specific selector (or restructuring your CSS) would solve it more cleanly.

4. Not Understanding `position: absolute`

.tooltip {
  position: absolute;
  top: 0;
  left: 0;
}

Beginners often expect this to position relative to the whole page. In reality, position: absolute positions relative to the nearest ancestor with position: relative (or absolute/fixed) set. If no ancestor has that, it positions relative to the whole document — which is rarely what you actually want.

The fix: always set position: relative on the parent container first:

.card {
  position: relative;
}
.badge {
  position: absolute;
  top: 8px;
  right: 8px;
}

5. Fighting Flexbox/Grid Instead of Reading the Docs

A very common beginner pattern: not getting the exact spacing/alignment you want, then adding random margins and padding until it "looks right" by trial and error.

The fix: learn justify-content, align-items, and gap properly (covered fully in Article 2). Once you understand these three properties, most alignment problems have a direct, one-line solution instead of a pile of guessed margins.

6. Not Resetting Default Browser Styles

Browsers apply their own default styles to elements (<ul> gets bullet points and padding, <h1> gets specific margins, etc.), and these defaults are inconsistent across browsers.

The fix: use a simple CSS reset at the top of your stylesheet, or use Tailwind CSS, which includes a solid reset (Preflight) automatically.

7. Specificity Wars from Nested Selectors

.card .header .title span {
  color: red;
}

Deeply nested selectors like this become extremely hard to override later, since they carry heavy specificity.

The fix: keep selectors as flat as possible. A single well-named class (.card-title) is easier to maintain than four levels of nesting.

Final Thoughts

Almost every CSS mistake on this list comes down to one thing: not understanding why the browser is doing what it's doing, and reaching for a quick patch instead. Once you understand the box model, specificity, and positioning contexts properly, CSS debugging goes from guesswork to genuinely logical problem-solving.

Muhammad Farhan is a Frontend Developer specializing in React.js and Tailwind CSS, based in Dera Ismail Khan, Pakistan.
Portfolio: Muhammad Farhan

Systems Thinking Beats Component Thinking, A Lesson From Human Anatomy

Mon, 24 Aug 2026 22:15:13 +0000

Most of us here debug systems for a living, and the best mental model I have found for cascading failure did not come out of a distributed systems paper. It came out of an anatomy guide, so bear with me for a minute.

The human body is usually taught as eleven organ systems, each with its own list of organs and its own list of functions. Students memorize the lists, pass the exam, and forget most of it, because a list is not a model. The version that sticks treats the eleven as one machine with eleven subsystems and a shared objective, which happens to be exactly how we are supposed to think about the services we run.

Eleven Subsystems, One Shared Objective

Every organ system exists to serve one goal: homeostasis, holding internal conditions inside a narrow band while the outside world keeps changing. Core temperature near 37 degrees Celsius. Blood pH between 7.35 and 7.45. Fasting blood glucose between 70 and 100 milligrams per deciliter.

Nothing in that architecture is decorative. Each subsystem has one job, and the job is defined relative to the shared objective rather than in isolation. That is the part that transfers. When a service in your stack cannot state its purpose in terms of the system level objective, it usually means nobody has decided what the objective is.

Failure Travels Along The Couplings

Kidney failure causes fluid retention, which strains the heart. Diabetes is an endocrine problem that goes on to damage blood vessels, nerves, kidneys and eyes. Chronic liver disease impairs clotting factor production, which shows up in the blood and eventually in the brain.

None of that is surprising once you have the dependency graph. It is very surprising when all you have is eleven separate lists. This is the same reason a connection pool exhaustion incident gets filed as a checkout outage: the symptom appears where the coupling ends, not where the fault started. Medicine moved toward a systems level approach for exactly this reason, and it is worth noticing that the field with the highest stakes got there first.

The Control Loop Is Already Familiar

Homeostasis runs on negative feedback. A sensor detects a deviation from a set point, a control center evaluates it, an effector corrects it. Blood glucose rises after a meal, the pancreas releases insulin, cells absorb glucose, levels come back down. Drop too low and glucagon does the reverse, telling the liver to put stored glucose back into circulation.

That is a control loop with a set point, an error signal and an actuator, which is to say it is your autoscaler. Positive feedback exists in the body too and it is rare, because it does not stabilize anything, it drives a process to completion. Blood clotting is the example: activated clotting factors activate more clotting factors until the wound is sealed. When that pattern shows up in software with no terminating condition, we call it a retry storm.

What To Take From It

Pick one event and trace it through the whole system instead of studying components one at a time. Climb a flight of stairs and six subsystems respond in the same second: muscles pull more glucose, the nervous system speeds the heart, breathing deepens, the adrenals release epinephrine, sweat glands open for thermoregulation, the kidneys hold fluid to protect blood pressure. One event, six subsystems, one objective.

If you want the biology properly, all eleven systems with their organs, functions and interactions laid out in one place, this guide covers it and it is where the examples above came from.

Do that same trace with an incident timeline and you will learn more in an afternoon than a month of reading service docs in isolation will teach you. The lists were never the point. The couplings were.

The Best Developers Don’t Fix Bugs, They Fix the Reason Bugs Exist

Mon, 17 Aug 2026 12:14:40 +0000

A bug is rarely just a bug.

Sometimes it is a missing validation.
Sometimes it is unclear requirements.
Sometimes it is technical debt.
And sometimes, it is simply a developer making an assumption that nobody questioned.

The easy response is:

“Let’s fix it.”

The better question is:

“Why was this bug possible in the first place?”

Fixing the symptom vs. fixing the system

Imagine a production API crashes because it receives an unexpected value.

A quick fix might be adding one if statement.

Problem solved?

Maybe.

But what if the same invalid data can enter through three other endpoints?

Now you fixed the symptom, not the problem.

Good developers look deeper:

Where did the bad data come from?
Why wasn't it validated earlier?
Why didn't the tests catch it?
Could the system make the same mistake again?
What can we change so this entire class of bugs becomes harder to create?

Every bug contains information

Instead of seeing bugs only as failures, treat them as feedback from your system.

A recurring bug might be telling you:

Your requirements are unclear.
Your tests are too narrow.
Your architecture has a weak boundary.
Your monitoring is insufficient.
Your team is repeating the same assumption.

The bug is simply the messenger.

A simple debugging habit

The next time you fix a production issue, spend 5 extra minutes asking:

1. What happened?
Understand the actual failure.

2. Why did it happen?
Find the root cause, not just the visible error.

3. Why wasn't it caught earlier?
Look at tests, reviews, monitoring, and processes.

4. How can we prevent the same category of failure?
Improve the system, not just the line of code.

🚀 The real goal of debugging

The goal isn't to have zero bugs.

That's unrealistic.

The goal is to build systems where:

bugs are detected earlier,
failures are easier to understand,
mistakes are harder to repeat,
and developers learn something from every incident.

Great developers don't just make bugs disappear. They make the next bug less likely.

What do you usually do after fixing a production bug—move on immediately, or investigate why it happened?

Sumita
Web Developer

Your Code Works. But Can You Explain Why?

Sat, 15 Aug 2026 18:48:06 +0000

There’s a dangerous stage in every developer’s career:

When the code works, but you don’t know why.

You change three things.
Restart the server.
Clear the cache.
Run it again.

Suddenly—it works. 🎉

But you haven’t actually fixed the problem.

You’ve only lost the evidence.

The Real Skill Isn’t Fixing Bugs

Good developers don’t just make errors disappear.

They ask:

What exactly failed?
Why did it fail?
What changed?
What evidence proves the fix?
Could the same bug happen somewhere else?

This mindset turns debugging from guessing into investigation.

Stop Changing Five Things at Once

Imagine a bug appears in production.

You change the database query, update a dependency, modify the API request, restart the service, and change a configuration value.

The problem disappears.

Now what do you know?

Almost nothing.

You don't know which change fixed it.

Instead:

Change one thing. Test. Observe. Learn.

It may feel slower, but it creates knowledge.

Errors Are Information

An error message isn't your enemy.

A stack trace isn't noise.

A failed test isn't wasted time.

They are clues.

The better you become at reading those clues, the less you depend on trial and error.

The Best Developers Build Mental Models

A senior developer doesn't necessarily know every solution.

They know how to find the solution.

When something breaks, they build a hypothesis:

“I think the problem is happening because X.”

Then they test it.

If they're wrong, that's useful too.

Now they know where the problem isn't.

One Simple Rule

Before changing your code, ask:

“What do I expect this change to prove?”

If you can't answer that, you're probably guessing.

Debugging isn't about making the error disappear as quickly as possible.

It's about learning why the error existed in the first place.

What’s one debugging habit that made you a better developer?

Sumita
Web Developer

The Code Worked Yesterday. What Changed?

Fri, 14 Aug 2026 09:07:19 +0000

One of the most frustrating moments in development is when code that worked perfectly yesterday suddenly stops working today.

You didn’t change the feature.

You didn’t intentionally modify the logic.

Yet suddenly:

The API returns an error.
The build fails.
A dependency breaks.
Tests start failing.
Production behaves differently from development.

So what happened?

The Hidden Problem: Software Doesn't Live Alone

We often think about our code as if it exists in isolation.

It doesn't.

Our applications depend on:

Libraries and frameworks
Operating systems
Databases
APIs
Cloud services
Environment variables
Third-party packages
Build tools
Infrastructure

Sometimes your code didn't break. Its environment changed.

The Developer Trap

When something breaks, the first instinct is often:

"What did I do wrong?"

That's not always the best question.

A better question is:

"What changed?"

Check the timeline.

What changed between the last known working state and the current failure?

Maybe:

A package was automatically updated.
An API changed its response.
A server configuration changed.
A certificate expired.
A database migration ran.
An environment variable disappeared.
A dependency introduced a breaking change.

A Simple Debugging Habit

Before changing code, compare the working and broken environments.

Ask:

1. What changed?
2. When did it change?
3. Who or what changed it?
4. Can I reproduce the failure?
5. Can I roll back the change?

This can save hours of random debugging.

The Bigger Lesson

Good developers don't just write code that works.

They build systems that make change visible.

That's why version locking, meaningful logs, monitoring, automated tests, CI/CD, dependency management, and configuration tracking matter.

The goal isn't to prevent every change.

The goal is to know what changed when something breaks.

Because debugging isn't always about finding the broken line.

Sometimes it's about finding the missing difference between yesterday and today.

What about you?

What's the strangest time your code suddenly stopped working even though you hadn't changed it?

Share the story — the weird ones usually teach developers the most.

The Best Developers Don’t Know Everything They Know How to Find Out

Fri, 14 Aug 2026 03:22:23 +0000

There’s a common misconception in software development:

Senior developers know the answers.

They don’t.

They simply know how to find the right answer without wasting hours.

A developer can’t memorize every API, framework, error message, database behavior, or cloud configuration. Technology changes too quickly.

What separates a strong developer from a struggling one is often the ability to investigate.

🔍 1. Read the Error Before Searching

A common habit is to immediately copy an error into Google or ChatGPT.

Instead, ask:

What exactly failed?
Which file and line caused it?
What changed recently?
Is this an application problem or an environment problem?

The error message often contains more information than we think.

🧠 2. Build a Hypothesis

Don't randomly change five things and hope the bug disappears.

Make a small hypothesis:

"I think this API is returning null because the authentication token isn't being passed."

Then test it.

If you're wrong, that's useful information too.

Debugging isn't guessing. It's reducing uncertainty.

📚 3. Learn to Read Documentation

Knowing how to search documentation is an underrated engineering skill.

Instead of searching:

"How do I make this work?"

Search for something specific:

"React useEffect cleanup behavior"

"PostgreSQL index query planner"

"Docker container environment variables"

Better questions produce better answers.

🤖 4. Use AI as an Investigator, Not an Oracle

AI can explain errors, suggest approaches, generate examples, and help you explore unfamiliar code.

But blindly accepting its answer creates another problem.

You still need to verify the result.

Ask AI:

"What assumptions are you making?"
"How can I test this?"
"What could make this solution fail?"
"Show me a simpler alternative."

The goal isn't to avoid thinking.

The goal is to think faster and better.

🛠️ 5. Keep Your Own Debugging Knowledge

Every difficult bug teaches you something.

Write down the important ones.

Not a huge documentation system.

Just short notes:

Problem → Investigation → Root Cause → Fix

After six months, you'll have something incredibly valuable:

Your own engineering playbook.

The Real Developer Skill

Frameworks will change.

Programming languages will evolve.

AI tools will improve.

But one skill will remain valuable:

The ability to turn "I don't know" into "I can figure this out."

That's what makes a developer adaptable.

What's one debugging or problem-solving technique you've learned that you now use almost every day?

The 10-Minute Rule: A Simple Way to Debug Software Faster

Wed, 12 Aug 2026 06:18:38 +0000

A bug appears in production.

Your first instinct is often to start changing code immediately.

Add a condition.
Change a query.
Restart the service.
Update a dependency.
Try something else.

Sometimes it works. But you may have no idea why it worked.

That is where debugging becomes dangerous.

The 10-Minute Rule

Before changing the code, spend the first 10 minutes understanding the problem.

Ask:

What exactly is failing?
When did it start?
Can I reproduce it?
What changed recently?
Is the problem in the frontend, backend, database, network, or deployment?
What does the error message actually tell me?

This small habit can save hours.

Stop Guessing. Start With Evidence.

Imagine an API suddenly returns 500.

A junior approach might be:

"The database must be broken."

A better approach is:

Check the application logs.
Identify the failing endpoint.
Check the request parameters.
Check database connectivity.
Look at the stack trace.
Reproduce the request locally.
Form a hypothesis.

Now you're debugging based on evidence instead of assumptions.

Don't Change Five Things at Once

One of the biggest debugging mistakes is making multiple changes simultaneously.

For example:

Update the dependency
Change the SQL query
Modify the API
Restart Docker
Clear the cache

Then the problem disappears.

Great!

But which change fixed it?

You don't know.

Instead, make one controlled change at a time whenever possible.

That gives you something much more valuable than a quick fix:

Understanding.

Read Error Messages Carefully

Error messages are often treated as annoying obstacles.

They shouldn't be.

A good error message can tell you:

Where the failure happened
What operation failed
Which value caused the problem
Which component reported the error
Sometimes even what should be fixed

Don't immediately search the entire error message online.

First, understand what it is telling you.

The Real Skill Is Building a Mental Model

Great debugging isn't about memorizing every error.

It's about understanding how your system works.

For example:

User → Browser → API → Service → Database → External API

When something breaks, ask:

"At which point did the expected behavior change?"

That question can dramatically reduce the search area.

Debugging Is Also Communication

In a team, saying:

"The API is broken."

isn't very useful.

Instead:

"The /orders endpoint started returning 500 errors after yesterday's deployment. The request reaches the service successfully, but the database query fails when customer_id is null."

Now another developer can immediately help.

Good debugging produces good information, not just fixes.

Final Thought

The fastest developer isn't always the person who types the fastest.

Sometimes it's the developer who stops typing and starts thinking.

Before changing the code, understand the failure.

Before guessing, collect evidence.

Before applying a fix, understand the cause.

Because a bug that disappears is not necessarily a bug that you solved.

Debug the problem. Don't just silence it.

Sumita
Web Developer

How to Fix EAS Build Failed Errors in Expo

Tue, 11 Aug 2026 11:46:41 +0000

There is a particular kind of Expo error that I think almost every developer eventually runs into.

You make a change to your project, run your usual build command:

eas build

and instead of getting a nice .apk or .aab at the end, you get:

Build failed

And that's it.

Well, not really.

If you open the build logs, you get several hundred lines of output containing Gradle tasks, Android dependencies, warnings, stack traces, environment information, and somewhere in the middle of all of that is the actual reason your build failed.

I've been there more times than I'd like to admit.

The frustrating part is that "EAS Build failed" isn't really an error by itself. EAS is just telling you that something went wrong during the build. The actual problem can be a completely different issue.

It might be an Android dependency conflict.

It might be a missing environment variable.

It might be an invalid app.json configuration.

It might be a native package that doesn't work with your current Expo SDK.

Or it might be something as simple as a credentials problem.

So instead of trying random fixes, let's go through how I approach these failures and how to find the actual cause.

First: Don't Focus on "EAS Build Failed"

When you see:

Build failed

it's tempting to search for that exact phrase.

The problem is that thousands of completely different problems can end with the same message.

EAS Build is responsible for building your application. It isn't necessarily responsible for the thing that broke.

For example, your log might eventually contain:

Execution failed for task ':app:mergeDexDebug'

That's an Android dependency/build problem.

Or:

Could not resolve all files for configuration

That's pointing toward dependency resolution.

Or you might see something related to:

Missing environment variable

That's an environment/configuration problem.

And if you see something related to signing credentials, you're dealing with an entirely different category of failure.

The first thing I do is therefore ignore the generic "Build failed" message and find the first meaningful error underneath it.

1. Open the Full EAS Build Logs

Start by looking at the failed build in the EAS dashboard.

You can also list recent builds from your terminal:

eas build:list

Find the failed build and open its logs.

Don't just look at the last few lines.

The last line might say:

Build failed

but that doesn't tell you much.

Instead, search through the logs for terms such as:

ERROR
FAILURE
Error:
Caused by:
Exception
Could not
Unable to

The useful error is often somewhere above the final failure message.

For example, imagine the bottom of your log looks like this:

> Task :app:mergeDexRelease FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:mergeDexRelease'.

> com.android.builder.dexing.DexArchiveMergerException:
  Error while merging dex archives

BUILD FAILED

Build failed

The useful information isn't really:

Build failed

It's:

Execution failed for task ':app:mergeDexRelease'

and whatever caused the DEX merge to fail.

That distinction saves a lot of time.

2. Check Whether the Problem Is Actually Your Expo Configuration

One of the first things I check after an EAS build fails is the project's configuration.

Depending on your setup, this can include:

app.json
app.config.js
app.config.ts
eas.json

A small configuration mistake can prevent the native project from being built correctly.

For example, if you've recently changed:

{
  "android": {
    "package": "com.example.myapp"
  }
}

or added a plugin:

{
  "plugins": [
    "some-native-package"
  ]
}

and the build immediately started failing, that change is worth investigating.

The same applies to permissions, native configuration, app identifiers, and Expo config plugins.

If the failure started immediately after a configuration change, don't assume the EAS service itself is broken.

Look at what changed in your project first.

3. Check Your Expo SDK and Native Dependencies

This is one of the biggest sources of trouble I've encountered with Expo projects.

Expo SDK versions are tied to specific versions of React Native and a collection of native dependencies.

You can have a perfectly valid JavaScript project and still break the native build by installing a package that doesn't fit your current environment.

For example:

npm install some-package

looks harmless.

But if that package contains native Android or iOS code, it becomes part of your native build.

That's where things can get interesting.

Before randomly upgrading packages, check your project:

npx expo-doctor

This can identify common dependency and configuration problems.

If you're using Expo, I also recommend using Expo's package installation command when appropriate:

npx expo install package-name

rather than blindly installing a version with npm.

Expo can select a version that is compatible with your current SDK.

4. If the Error Mentions Gradle, Investigate the Android Build

Sometimes an EAS failure is actually an Android build failure hiding underneath Expo.

For example:

Execution failed for task ':app:mergeDexRelease'

or:

Could not resolve all files for configuration

or:

Duplicate class found

These are not really "Expo errors."

They're Android/Gradle dependency problems occurring during your Expo build.

This distinction matters because searching for:

EAS Build failed

will give you a huge number of unrelated results.

Searching for:

Execution failed for task mergeDexRelease React Native

is much more useful.

That's generally how I approach these logs: follow the most specific error rather than the generic EAS failure.

5. Check Your Environment Variables

Another surprisingly common cause of failed builds is an environment variable that exists locally but doesn't exist in EAS.

For example, your application might expect:

API_URL
SUPABASE_URL
SUPABASE_ANON_KEY

Your local development environment works because those variables exist in your .env file.

Then you create an EAS build and suddenly something breaks.

Why?

Because the remote build environment doesn't automatically have every variable from your local machine.

Check your EAS environment configuration:

eas env:list

Make sure the variables your application actually needs are available in the environment being used for the build.

This is especially important if the failure happens only on EAS while:

npx expo start

works perfectly locally.

6. Check Your EAS Build Profile

Your eas.json determines how your builds are configured.

A typical configuration might look something like:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

If the problem only happens with one profile, compare that profile with the one that works.

For example:

eas build --profile preview

might work while:

eas build --profile production

fails.

That immediately gives you another clue.

The problem may not be your entire project. It may be something specific to the build profile.

7. Don't Ignore Credentials Errors

If the log mentions things such as:

credentials
keystore
provisioning profile
certificate
signing

don't start changing Gradle dependencies.

You're probably dealing with app signing or build credentials instead.

For Android, EAS can manage your app signing credentials for you.

You can inspect the credentials with:

eas credentials

If the error is specifically about signing, work through the credential configuration rather than treating it like a code or dependency problem.

This is one of those situations where identifying the category of the error is much more useful than knowing a particular command.

8. If It Worked Before, Ask What Changed

This is probably my favorite debugging question:

What changed immediately before the build started failing?

Don't underestimate how useful this is.

If yesterday you had:

EAS build → SUCCESS

and today you have:

EAS build → FAILED

something changed.

Maybe you:

installed a package
upgraded Expo
changed app.json
changed eas.json
modified environment variables
changed an Android dependency
added a config plugin
changed native code

Start there.

For example, if the failure appeared immediately after:

npx expo install some-package

I would investigate that package before touching ten unrelated parts of the project.

9. Clean Up Before Rebuilding

If you've already made changes trying to fix the problem, make sure you're not debugging an old local state.

For a native project, a clean build can sometimes help:

cd android
./gradlew clean
cd ..

For Expo projects using prebuild, you may also need to regenerate native projects depending on your setup.

But don't use cleaning as your first response to every error.

If the build is failing because a dependency is genuinely incompatible, cleaning won't magically make the dependency compatible.

It only removes cached/generated build artifacts.

The Most Important Part: Find the Root Error

This is the part that took me the longest to appreciate.

When a build log contains hundreds of lines, the error at the bottom isn't necessarily the error you need to fix.

For example:

Task :app:assembleRelease FAILED

is not particularly useful.

Neither is:

Build failed

The useful part might be 30, 50, or even 200 lines above it.

You might eventually find:

Duplicate class androidx.lifecycle.ViewModel

And suddenly the whole situation makes sense.

Or:

Could not resolve com.google.firebase:...

Now you're dealing with a dependency resolution problem.

Or:

Missing environment variable: API_URL

Now you know exactly where to look.

The final error tells you that the build stopped. The underlying error tells you why.

What If Your Error Doesn't Match Any Of These?

This is where things get much more frustrating.

You can search the exact error message and find ten different Stack Overflow answers.

One says to upgrade Gradle.

Another says to delete node_modules.

Another says to run expo prebuild --clean.

Someone else says to downgrade React Native.

And suddenly you're changing five different things without knowing which one actually matters.

I've made that mistake myself.

The problem with large React Native and Expo build logs is that they often contain a lot of information but very little prioritization.

You don't necessarily need another list of 15 possible fixes.

You need to know:

Which part of this particular log is actually causing the failure?

That's also the problem I wanted to solve with FixMyError.

Instead of manually digging through a huge React Native or Expo error log and trying to decide which line matters, you can paste the log into FixMyError and get a focused diagnosis aimed at identifying the most likely cause and the first fix worth trying.

It's particularly useful when your error doesn't fit neatly into one of the common categories above and you're staring at a wall of Gradle, Expo, or native build output wondering where to even start.

You don't need to use it for every error. If the log clearly tells you what's wrong, fix it and move on.

But when the useful information is buried somewhere inside a massive build log, that's exactly when a diagnostic tool becomes useful.

A Simple Workflow I Use Now

When an Expo EAS build fails, I don't immediately start changing dependencies or upgrading packages.

I go through this:

1. Find the actual failure

Don't stop at:

Build failed

Find the underlying error.

2. Identify the category

Is it:

configuration?
dependency?
Android/Gradle?
iOS/Xcode?
environment variables?
credentials?
native module compatibility?

3. Ask what changed

What did you install, upgrade, or modify immediately before the failure?

4. Check the full log

Don't assume the last error line is the root cause.

5. Run the relevant diagnostic tools

For example:

npx expo-doctor

and inspect your EAS configuration and dependencies.

6. Change one thing at a time

Don't simultaneously upgrade Expo, downgrade Gradle, delete node_modules, regenerate native projects, and change your dependencies.

If the build starts working afterward, you won't know what actually fixed it.

7. If the log is still unclear, diagnose the log itself

That's where a tool like FixMyError can save time.

Final Thoughts

An EAS Build failed message can look like a single problem, but it really isn't.

EAS is just the environment where the failure becomes visible.

The actual cause might be hiding in:

Expo configuration
native dependencies
Gradle
Xcode
environment variables
credentials
config plugins
or a package that isn't compatible with your current SDK

The biggest improvement you can make to your debugging process is to stop treating:

Build failed

as the error.

Treat it as the symptom.

Then work backward until you find the first specific failure that actually explains what happened.

And if you're staring at a huge build log and can't tell which of the hundreds of lines actually matters, that's precisely the kind of situation where having something analyze the error for you can be useful.

Happy debugging.

The Bug Wasn't in the Code: Why Developers Debug the Wrong Layer

Tue, 11 Aug 2026 07:06:55 +0000

The Bug Wasn't in the Code: Why Developers Debug the Wrong Layer

One of the most frustrating debugging experiences is spending hours fixing code that was never actually broken.

You inspect the function.

You add logs.

You rewrite the query.

You restart the server.

You blame the framework.

And then you discover the real problem was a configuration variable, a stale cache, an expired token, or a request that never reached your application.

Sometimes the biggest debugging mistake is starting at the wrong layer.

The Application Isn't the Whole System

Modern applications rarely work in isolation.

A simple button click might involve:

Browser
Frontend application
API gateway
Backend service
Authentication service
Database
Cache
Message queue
External API
Cloud infrastructure

When something fails, developers often immediately open the backend code.

But what if the request never reached the backend?

Or what if the backend returned the correct response, but the frontend interpreted it incorrectly?

Debugging should follow the path of the request, not your assumptions.

Start With the First Known Failure

Instead of asking:

"Where is the bug?"

Ask:

"Where does the system first behave differently from what I expected?"

For example:

User clicks "Save".
Browser sends a request.
API receives the request.
Backend validates the data.
Database stores the record.
Backend returns success.
Frontend updates the UI.

If the UI doesn't show the saved record, don't immediately change the database query.

First determine:

Did the request leave the browser?

Then:

Did the API receive it?

Then:

Did the database operation succeed?

Then:

Did the response contain what the frontend expected?

This turns debugging from guessing into investigation.

Logs Are Evidence, Not Decoration

A lot of applications have logs everywhere, but developers still struggle to debug them.

Why?

Because the logs don't tell a story.

A useful log should help answer:

What happened?
When did it happen?
Which request caused it?
Which user/session/request ID was involved?
Which service handled it?
What was the result?

A request ID can be incredibly valuable.

For example:

Request ID: 8f21a

Frontend
→ POST /orders

API
→ Request received

Order Service
→ Payment validation started

Payment Service
→ Timeout

Order Service
→ Order creation failed

Now you don't need to guess where the problem is.

The system is showing you the path.

Don't Change Five Things at Once

This is one of the most common debugging mistakes.

You see an error and change:

The database query
The API code
The frontend state
The configuration
The dependency version

Then the problem disappears.

Great?

Not really.

You don't know which change fixed it.

A better approach is:

One hypothesis → one change → one observation.

This might feel slower, but it creates knowledge instead of luck.

Production Bugs Need a Different Mindset

Local development gives you a controlled environment.

Production doesn't.

Production may have:

Different environment variables
Different traffic
Different database size
Different permissions
Different network rules
Different caching behavior
Different dependency versions
Real concurrency

That's why:

"It works on my machine" is not a debugging strategy.

You need to compare environments systematically.

The Best Debuggers Think in Layers

When something breaks, move through the system layer by layer:

1. Client

Did the browser/mobile app send the expected request?

2. Network

Did the request reach the correct destination?

3. API

Did the server receive and process it?

4. Business Logic

Did the application make the correct decision?

5. Database

Was the data actually read or written?

6. Infrastructure

Were containers, servers, queues, DNS, or cloud services healthy?

7. External Dependencies

Did a third-party service respond correctly?

This simple mental model prevents you from spending two hours debugging a function when the actual problem is DNS.

Debugging Is About Reducing Uncertainty

Good debugging isn't about being the smartest person in the room.

It's about systematically removing possibilities.

Instead of:

"Maybe the database is broken."

Ask:

"Can I prove the database received the query?"

Instead of:

"The API must be returning bad data."

Ask:

"What exact response did the API return?"

Instead of:

"React isn't updating."

Ask:

"Did React receive the new state?"

Every question should reduce the number of possible explanations.

Final Thought

The fastest developers aren't necessarily the ones who type the fastest.

They're the ones who make fewer random changes.

When a bug appears, don't immediately open the file where you think the problem lives.

Follow the request.

Collect evidence.

Find the first unexpected behavior.

Then fix the smallest thing that explains it.

Because sometimes the code isn't broken.

Your mental model of the system is.

Sumita
Web Developer

Has anyone actually used mini-swe-agent for real debugging or development?

Sun, 09 Aug 2026 01:18:05 +0000

DeepSWE's harness comparison made me curious, so I tried mini-swe-agent myself on a matched set of debugging tasks with GPT-5.6 SOL at High reasoning.

The current numbers surprised me:

Codex CLI High: 151.91M tokens, 60% pass rate
plain mini-swe-agent: 70.33M tokens, 67%
the same mini harness plus macro execution, without changing the prompt: 60.59M tokens, 78%

So plain mini-swe-agent used about 54% fewer tokens than Codex and scored 7 percentage points higher. In the smaller ablation, changing only execution cut another ~14% of tokens and added 11 points.

That does not prove it is universally better. It is one matched benchmark slice, and DeepSWE itself notes that prompt tuning may explain part of the harness gap. Still, for debugging, the very small “bash + linear history” setup looks unusually strong.

Has anyone used it for day-to-day bug fixing or feature work? What breaks first outside a benchmark: repository setup, long-running tests, permissions, or patch quality?

Disclosure: I maintain Tura and ran the benchmark above.

Persister Cells: The Bug That Survives Every Retry Isn't Resistant, It's Dormant

Tue, 04 Aug 2026 03:36:09 +0000

Originally published on Vibe Agent Making.

In 1944, the physician Joseph Bigger hit a Staphylococcus culture with penicillin and watched almost all of it die. A tiny remnant survived, which is unremarkable. The interesting part: he regrew the survivors and hit them again, and they died just as thoroughly as the first time. The survivors hadn't become tougher; their offspring were exactly as vulnerable. Whatever let that remnant live wasn't heritable and wasn't a matter of overpowering the drug. Bigger called them "persisters," and the word is precise: they didn't resist the penicillin, they persisted through it. That distinction is the whole story of the most maddening class of bug you'll ever chase: the one that survives every restart, every retry, every careful remediation, and comes back identical, as if you'd done nothing.

The drug needs a moving target

Most antibiotics don't work like poison on a fixed structure. They sabotage growth: beta-lactams jam cell-wall construction (the cell tries to divide and bursts); quinolones corrupt DNA replication. The killing requires growth. A persister cell stops moving: it goes dormant, throttles its metabolism, does nothing, and a cell doing nothing presents nothing for a growth-targeting drug to attack. The 2019 Nature Reviews Microbiology consensus paper calls the targets in non-growing cells "recalcitrant": not defended, just absent from the fight. The drug washes harmlessly over the sleeping handful; treatment ends, they wake, and they rebuild the whole population. The infection relapses, genetically identical and fully susceptible. The survivors are not the strong ones. As Kim Lewis put it in 2007, the tolerance "is not inherited and is reversible. Persisters are not mutants, but rather dormant cells." Strength was never the variable. Activity was.

The shape of the failure tells you what it is

Persistence leaves a fingerprint. Plot survivors against time under treatment: a resistant strain gives a flat-ish line (it grows under the drug), but a persister population gives a two-phase curve, the bulk dying fast (a steep cliff) and then a long, stubborn tail the drug can't finish. That's the biphasic killing curve, and it says: not resistance, dormancy.

The vocabulary is load-bearing. Resistance: a heritable change that lets a cell grow at drug concentrations that would kill its ancestors (it defeats the drug and passes it on). Tolerance: a whole population dies more slowly without growing under the drug (buys time, not victory). Persistence: a special case of tolerance, a subpopulation that survives far better than the rest, the tail of the curve. The one-liner from the 2019 paper: resistant mutants can divide during treatment; persisters can only survive. One fights, the other waits.

Your retry is the antibiotic

When a fault survives every restart and retry, the reflex is to call it "hard", a deep, well-defended bug resisting your fix. Sometimes. Far more often it isn't resistant, it's dormant, and it survives for Bigger's reason: your remediation only hits the part of the system that's active.

The cleanest documented case is anthropics/claude-code issue #23081: a connection drops, retry logic kicks in, and the retry keeps failing the same way because it reuses stale connection state, the HTTP/2 pool, the cached TLS session, the DNS entry. The "fresh" attempt reaches back into the pool and re-serves the poisoned connection. The fix isn't to retry harder; it's to destroy and recreate the client (flush the pool and TLS cache) before retrying. Your retry was the antibiotic; it hit the active path with full force; the dormant connection survived precisely because it was doing nothing when you struck.

The shape is everywhere: the pool that hands back a dead connection after idle time ("intermittent, only after a period of idleness when traffic picks back up"); the lagging replica that's quiet during your fix on the primary and then reconnects and re-seeds stale state; the cached bad config, the queued-but-not-running job, the sleeping cron, the in-memory singleton holding a pre-fix value. Each is a place a fault can be dormant during your remediation. And the tell: the restart that helps but doesn't last. Microsoft's docs on connection-pool exhaustion say restarting "helps clear stale connections... typically a temporary solution rather than addressing root causes", which is the biphasic curve in plain English. A fix that works beautifully for ten minutes and relapses under load isn't flaky; it's a persister waking up.

The misdiagnosis is the whole trap

Resistance and persistence need opposite responses, and mixing them up keeps you fighting forever. When a fix doesn't stick, the instinct is to escalate force: retry harder, restart more aggressively, add retries to the backoff. That's exactly right against a resistant fault, one that actively defeats your fix and spreads under it. But against a persister, escalated force is worse than wasted, it's invisible: force tuned to the active population can't touch what's asleep, by definition. Triple your retries against a stale pool and you re-serve the poisoned connection three times as fast. The persister isn't beating your fix; it's ignoring it. Hammering the active symptom while the dormant pool waits you out is the most common way good engineers lose days to a bug a five-minute cache flush would have ended.

So the question is not "how do I hit this harder?" It's "what part of this system was asleep while I was fixing it?" And there's a sting: the Cell (2014) work links persistence to a higher risk of true resistance emerging during treatment, because the dormant survivors buy the time evolution needs. The software echo is faithful: the cached corruption that sits long enough to become the trusted value; the stale replica that, because it happened to be up, gets promoted to source of truth. Leave the reservoir unflushed and a recurring fault gets baked into structure. Clear it before it sets.

The clinician's discipline

Read the curve before you escalate. Kills-most-then-a-stubborn-fraction-returns is the diagnosis: a persister, not a resistant bug. More force is the wrong instrument.
Enumerate the dormant reservoirs before you re-fix. Explicitly, every time: caches, queues, idle pools, sleeping crons, offline/lagging replicas, persisted session state, in-memory singletons. Anywhere the fault could be asleep during remediation.
Flush, don't hammer. Invalidate caches, drain queues, destroy and recreate the pool, quiesce and rebuild idle replicas. Eradicate the reservoir, don't escalate force on the visible symptom.
Quiesce before you fix (the most clinical move). Stop or drain the dormant population first so it can't re-seed mid-repair: take the lagging replica out of rotation, drain the queue, empty the pool, fix the quiet system, then bring the rest back. Otherwise you apply the same fix four times.
Verify across the relapse window. Don't declare victory at the restart; confirm the fault doesn't return when load resumes and the idle parts wake, the moment the "antibiotic concentration drops." That's finishing the full course instead of stopping when you feel better, which is exactly the behavior that breeds persisters.

Survival isn't strength. The fault that laughs at every retry usually isn't tougher than your fix, it's asleep during it. Stop hitting the part that's awake. Find the part that's dormant, and flush the reservoir.

An AI agent that keeps relapsing into the same failure is rarely fighting your fix; it's reusing dormant state the retry never touched, a cached belief, a stale piece of context, a poisoned memory carried across attempts. You can only find the reservoir if you can read what the agent actually did each time. Chain of Consciousness is that record: a tamper-evident chain of an agent's reasoning, tools, and actions across attempts, so you can see the biphasic curve in its behavior, spot the state that survived the restart, and flush it instead of hammering the part that was already awake. pip install chain-of-consciousness / npm install chain-of-consciousness.

Why Great Developers Read Error Messages Before Writing Code

Fri, 31 Jul 2026 17:13:54 +0000

Every developer has done it: you run your application, something breaks, and your first instinct is to start changing code. Five edits later, the original problem is still there—and now you've introduced two new bugs.

The fastest developers aren't necessarily the best coders. They're often the best investigators.

The Error Message Is Usually the First Clue

Error messages aren't your enemy. They're your debugging assistant.

Instead of ignoring them, ask these questions:

What file is mentioned?
What line number is referenced?
What exception occurred?
What happened immediately before the error?

A surprising number of issues can be solved just by carefully reading the entire stack trace.

Stop Guessing, Start Testing

Randomly changing code rarely solves complex problems.

A better workflow looks like this:

Reproduce the issue consistently.
Read the complete error.
Form one hypothesis.
Test only that hypothesis.
Repeat until the root cause is found.

This approach is slower for the first five minutes—but much faster overall.

Common Mistakes Developers Make
Skipping the Stack Trace

Many developers read only the first line of an error.

The real answer is often buried several lines deeper.

Copying the Error into AI Without Context

AI can help, but if you only paste the error message, you'll often get generic advice.

Include:

The relevant code
Framework version
Expected behavior
Actual behavior
Steps to reproduce

Better context produces better answers.

Fixing Symptoms Instead of Causes

Imagine your application crashes because a value is null.

Changing:

if (user) {
...
}

might stop the crash.

But why was user null in the first place?

That's the real bug.

Build a Debugging Mindset

Professional developers don't panic when something breaks.

They collect evidence.

Think like a detective:

What changed recently?
Can I reproduce it?
Does it happen everywhere or only sometimes?
What assumptions am I making?

These questions often reveal the answer before you even touch the code.

Use Your Tools

Modern IDEs and browsers provide incredible debugging tools:

Breakpoints
Variable inspection
Network monitoring
Performance profiling
Log filtering

Learning these tools will save far more time than memorizing another framework.

Final Thoughts

Writing code is only half of software development.

The other half is understanding why code behaves the way it does.

The next time an error appears, resist the urge to immediately start editing files.

Read first. Think second. Change code last.

You'll solve bugs faster—and become a much stronger developer in the process.

Sumita
Web Developer

Why Most Developers Never Read Their Own Logs (And It Costs Them Hours)

Fri, 31 Jul 2026 08:09:41 +0000

When something breaks, many developers immediately start changing code, adding console.log() statements, or searching Stack Overflow. Ironically, the answer is often already sitting in the application's logs—they just never read them carefully.

Logs aren't just for production monitoring. They're one of the fastest ways to understand what your application is actually doing.

The Hidden Cost of Ignoring Logs

Imagine a user reports that checkout fails randomly.

Many developers will:

Add more debug statements.
Restart the application.
Try to reproduce the issue dozens of times.
Assume it's a frontend bug.

Meanwhile, the existing logs already show:

Database connection timeout
Third-party API returning 429 (Rate Limit)
Authentication token expired
Missing environment variable

The information was there all along.

Good Logs Tell a Story

A useful log answers questions like:

What happened?
When did it happen?
Which user or request was affected?
Which service generated the error?
What happened immediately before the failure?

Instead of logging:

Error occurred

Log something meaningful:

Order creation failed
Order ID: 48291
User: 1542
Payment Gateway: Stripe
Status: Timeout
Retry Count: 2

Now debugging takes minutes instead of hours.

Logging Is Not Just About Errors

Many developers only log exceptions.

The best systems also log:

User authentication
API requests
Database execution time
Cache hits and misses
Background jobs
Queue processing
External API calls

These events help explain why an issue happened—not just that it happened.

Avoid These Common Mistakes

❌ Logging passwords or sensitive data

❌ Writing huge log files with unnecessary information

❌ Using different log formats across services

❌ Ignoring warning messages

❌ Never rotating or cleaning log files

Structured Logs Make Life Easier

Instead of plain text, many teams use structured JSON logs.

Example:

{
"level":"ERROR",
"service":"payment-api",
"userId":1542,
"orderId":48291,
"message":"Gateway timeout"
}

These logs are much easier to search and analyze using tools like Elasticsearch, Grafana, or cloud logging platforms.

Build the Habit

The next time you face a bug:

Read the logs first.
Follow the request from start to finish.
Look for warnings before the error.
Check timestamps.
Verify external service responses.

You'll often solve the issue before writing a single new line of code.

Final Thoughts

Great debugging isn't about guessing—it's about gathering evidence. Your logs are one of the richest sources of that evidence. The more intentionally you log today, the less time you'll spend chasing mysterious bugs tomorrow.

How to Fix "Duplicate class ... found in modules" in React Native & Expo

Thu, 23 Jul 2026 12:36:11 +0000

If you've been developing with React Native or Expo for a while, chances are you've had a project that suddenly refuses to build for what seems like no reason.

Maybe you installed a new package. Maybe you upgraded Expo. Maybe you only changed a single dependency. You confidently run your Android build, expecting it to compile like always...

Instead, Gradle greets you with something like this:

Execution failed for task ':app:checkDebugDuplicateClasses'.

Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.8.2.aar and lifecycle-viewmodel-ktx-2.6.1.aar

Duplicate class com.google.android.gms.internal.measurement.zzab found in modules play-services-measurement-base-22.0.0.aar and play-services-measurement-impl-21.6.2.aar

Duplicate class ...

At first glance, the error looks straightforward: there are duplicate classes. Easy enough, right?

Not exactly.

In reality, this is one of those Android build errors that can send you down a rabbit hole of Gradle files, dependency trees and Stack Overflow threads, only to realize the real cause was something completely different.

Let's break down what's actually happening and, more importantly, how to fix it.

Why this error happens

Every Android library included in your project contains compiled Java or Kotlin classes.

When Gradle builds your application, it combines all of those libraries into a single APK or AAB.

If two different dependencies contain the exact same class, Gradle doesn't know which version should be packaged.

Instead of guessing, it stops the build with a Duplicate class error.

The difficult part is that the dependency causing the conflict usually isn't the one shown in the error.

Very often, it's another package pulling in an older or incompatible version behind the scenes.

The most common causes

After seeing this error many times, these are usually the culprits.

1. Two libraries depend on different versions of the same package

This is by far the most common scenario.

For example:

Library A requires:

androidx.lifecycle:lifecycle-viewmodel:2.8.2

while Library B depends on:

androidx.lifecycle:lifecycle-viewmodel:2.6.1

Both versions get added to your dependency graph, eventually leading to duplicate classes.

2. An outdated React Native package

Older React Native libraries often haven't been updated for newer AndroidX or Google Play Services versions.

Even though your project is current, that one dependency may still reference libraries released years ago.

3. Expo SDK upgrades

After upgrading Expo, many native dependency versions change.

If one third-party package hasn't caught up yet, Gradle may end up resolving incompatible versions.

This is especially common immediately after major SDK releases.

4. Mixing manual native configuration with Expo-managed dependencies

Sometimes developers manually add Android dependencies that Expo already manages internally.

The result is two copies of essentially the same library.

How to fix it

There isn't one universal solution, but these steps solve the majority of cases.

Step 1 — Read the duplicated class carefully

Don't focus on the entire error.

Look specifically for the two modules involved.

For example:

lifecycle-viewmodel-2.8.2

lifecycle-viewmodel-ktx-2.6.1

Those names usually point you toward the conflicting dependency.

Step 2 — Find who is importing it

Run:

./gradlew app:dependencies

./gradlew app:dependencyInsight --dependency lifecycle-viewmodel

This shows which package is pulling each version into your project.

It's much faster than guessing.

Step 3 — Update outdated packages

If one library is significantly behind, updating it often resolves the conflict immediately.

Always check whether a newer version exists before trying complicated Gradle workarounds.

Step 4 — Clean the project

Sometimes Gradle continues using cached artifacts.

Try:

cd android

./gradlew clean

Then rebuild.

Step 5 — Regenerate native files (Expo)

If you're using Expo Prebuild:

npx expo prebuild --clean

This recreates the native Android project using your current configuration.

Step 6 — Force dependency versions (only if necessary)

Sometimes you need to force Gradle to use one specific version.

For example:

configurations.all {
    resolutionStrategy {
        force "androidx.lifecycle:lifecycle-viewmodel:2.8.2"
    }
}

Use this carefully.

If two libraries genuinely require incompatible versions, forcing one version may create runtime problems later.

How to avoid this error in the future

While duplicate class errors can't always be prevented, these habits reduce the chances considerably.

Keep Expo SDKs reasonably up to date.
Avoid abandoned React Native libraries.
Update dependencies together instead of one at a time.
Review package compatibility before major upgrades.
Avoid manually adding Android dependencies unless absolutely necessary.

When the error isn't actually the problem

One thing that makes this error frustrating is that the duplicate classes are often just a symptom.

The real issue might be:

an outdated library,
conflicting Firebase dependencies,
mixed AndroidX versions,
incompatible Google Play Services packages,
or an incomplete Expo migration.

That's why simply searching the duplicated class name doesn't always lead to the correct fix.

Understanding why those dependencies ended up together is usually more important than the class itself.

How FixMyError can help

Instead of manually digging through Gradle output, dependency trees and dozens of forum posts, you can paste the full error into FixMyError.

The tool analyzes the build log, identifies the likely source of the conflict, explains what's happening in plain English, and suggests fixes based on the specific dependencies involved.

Rather than treating every duplicate class error as identical, it tries to narrow the problem down to the actual cause behind your particular build failure.

Final thoughts

Duplicate class errors are among the most frustrating Android build issues because the message rarely points directly to the package that's responsible.

The good news is that, in most cases, the problem comes down to dependency resolution rather than something fundamentally broken in your project.

Once you identify which libraries are introducing conflicting versions, the fix usually becomes much more straightforward.

If you're currently staring at a wall of Gradle output wondering where to begin, start by identifying the conflicting modules, trace where they're coming from, and work outward from there.

It takes a bit of patience, but it's almost always easier than blindly trying random fixes from different Stack Overflow threads.

The Bug That Wasn't a Bug: Why Your First Instinct Is Almost Always Wrong

Tue, 21 Jul 2026 09:59:28 +0000

You've been staring at the same 40 lines of code for two hours. You're convinced the problem is in the database query. You've rewritten it three times. You've Googled the same error message so many times that it's now in your browser autocomplete. You've blamed the ORM, the driver, the network, the moon.

The bug is in line 7. It's a missing await.

Sound familiar? Welcome to debugging — where your first instinct is almost always wrong, and the sooner you accept that, the faster you actually fix things.

The Curse of the Expert Guesser

Here's what happens when most developers hit a bug:

They read the error message (briefly)
They form a theory about the cause
They go looking for evidence that confirms the theory
They find something that looks like evidence
They fix the wrong thing
They are confused when it doesn't work
They repeat steps 1–6 three more times

This is called confirmation bias, and it is absolutely devastating in debugging. Your brain is not trying to find the truth — it's trying to prove itself right. And it's annoyingly good at that.

The moment you think "I bet it's the cache," you will find seventeen things that look like cache problems. The cache is probably fine. The cache is almost always fine.

The Fix: Treat Debugging Like a Science Experiment

Good debugging is not guessing with confidence. It's forming a hypothesis and then actively trying to disprove it.

Ask yourself: "If I am wrong about this, what would that look like?"

If your theory is that the database query is slow, what does it look like if the query is actually fast? Check. Actually measure. Don't assume. The fastest way to find a bug is to ruthlessly eliminate what the bug is not.

This sounds obvious. Nobody does it.

Instead, most of us do this:

# Something is wrong. Let's add print statements everywhere.
print("here 1")
print("here 2")
print(data)
print("here 3 - still broken")
print("WHY")

Which is fine — but only if you're actually reading the output and updating your theory based on what you see, not just hunting for confirmation.

The Real Reason Debugging is Hard

It's not the complexity of the code. It's the distance between the symptom and the cause.

The error appears in the frontend. The bug is in the backend validation logic. The test fails in CI. The bug only exists when environment variables are loaded in a certain order. The app crashes in production. The bug is a timezone issue that only surfaces in UTC+2 on Tuesdays.

Most bugs are not where they appear. They are upstream. Something failed, something else caught it silently, something else passed bad data forward, and eventually something blew up three layers away from where the original sin happened.

So when you see an error, your first question shouldn't be "what's broken here?" It should be "what gave this code bad input?"

Trace backwards. Always trace backwards.

Things I've Learned the Embarrassing Way

Read the full error message. Not the first line. The whole thing. The part you need is usually at the bottom, and you've been ignoring it because you formed a theory at line one.

Rubber duck it early. The moment you start writing a Stack Overflow question and you have to actually describe what you tried, you will frequently solve your own problem before you hit Post. The rubber duck does not care how long you've been coding. It just wants you to explain it clearly. Explaining it clearly forces you to think clearly.

The last thing you changed broke it. I know you don't want to hear this. I know you were just "cleaning up." You broke it. Check git diff.

If it works on your machine and not in production, the environments are different. Not slightly. Fundamentally. Find the difference before you do anything else. Environment variables, versions, file paths, memory limits — something is different. Find it.

Sleep is a debugging tool. I don't know why this works. Your brain does something when you stop looking at it. You will wake up at 3 am and know exactly what's wrong. Happens to everyone.

The Bug That Wasn't a Bug (For Real This Time)

Once, I spent an entire afternoon convinced a third-party API was returning inconsistent data. I logged everything. I added retries. I considered switching providers. I drafted an angry support ticket.

The API was fine.

I was passing a parameter name with a capital letter instead of lowercase. The API silently ignored it and returned defaults every single time. Consistent. Predictable. Not a bug at all. Completely my fault.

The real lesson isn't "check your parameter names" (although yes, check your parameter names). The lesson is that the system was behaving exactly as designed. I was wrong about the contract. My understanding was the bug, not the code.

A lot of bugs are like this. The code is doing exactly what you told it to do. You told it to do the wrong thing.

One Practical Habit That Will Actually Help

When you've been stuck for more than 30 minutes, write down — physically or in a comment — exactly what you believe is happening and why. Not what you want to be happening. What you believe is actually happening right now.

Then look at what you wrote. Is each sentence something you measured, or something you assumed? The assumptions are where the bug lives.

Most bugs are not mysterious. They're just hiding inside something you were too confident about to check.

Go check it.

How to fix `global._getAnimationTimestamp is not a function` After Upgrading to Expo SDK 55

Thu, 16 Jul 2026 09:53:20 +0000

I recently spent far more time than I'd like to admit chasing down a hard crash after upgrading a project from Expo SDK 54 to 55.

The app launched fine. Navigation worked. Everything looked normal.

Then the moment a Reanimated animation fired, the app exploded with a red screen:

Render Error

global._getAnimationTimestamp is not a function (it is undefined)

In my case, the crash happened inside a useEffect that called withTiming() on a shared value when a tab gained focus.

My first assumption was a dependency mismatch between react-native-reanimated and react-native-worklets. I checked versions, verified the dependency tree, and even started looking for Babel configuration issues.

Everything looked correct.

As it turns out, the problem wasn't in the JavaScript code at all.

What Is Actually Happening?

At first glance, this error looks like a breaking change inside Reanimated or a bad project configuration.

In reality, it's usually a sync problem between your JavaScript bundle and your native application binary.

The important clue is the function name itself:

_getAnimationTimestamp

This isn't a function your application calls directly. It's one of the internal functions Reanimated expects to find in the native runtime.

Reanimated relies heavily on JSI (JavaScript Interface) to bridge JavaScript directly to native C++ code for performance-critical animation work.

When you upgrade to Expo SDK 55, Reanimated gets upgraded as well (typically from 4.1.x to 4.2.x, depending on your project).

Your Metro server immediately starts serving the updated JavaScript bundle.

The problem is that your custom development client is still running the native code that was compiled before the upgrade.

Now you have two different versions talking to each other:

The JavaScript side expects the newer Reanimated runtime.
The native side is still exposing the older implementation.

The updated JavaScript bundle expects _getAnimationTimestamp to exist.

Your older native client doesn't provide that function yet.

The moment Reanimated tries to use it, the app crashes.

Why Reinstalling Dependencies Doesn't Help

I went through the usual checklist first:

Reinstall dependencies
Verify package versions
Check Babel configuration
Clear node_modules
Run npm install again

None of it fixed the issue.

That's because the problem isn't living in your JavaScript dependencies.

Your packages can be perfectly correct while your device or simulator is still running an outdated native binary.

As long as the native client wasn't rebuilt after the upgrade, the crash will continue to happen.

When You'll Usually See This Error

One thing worth mentioning is that this mostly shows up when you're using a custom development client.

If you're using Expo Go, Expo manages the native runtime for you, so JavaScript and native code generally stay in sync.

This issue is much more common when you're working with:

Custom dev-clients
expo run:android
expo run:ios
Development builds generated through EAS

In those environments, it's entirely possible for Metro to be serving new JavaScript while your device is still running an older native build.

The Fix

A normal JavaScript reload won't solve this.

Pressing r in the Metro terminal only refreshes the JavaScript bundle. It does not rebuild the native application.

To fix the issue, you need both sides of the application running the same version.

Step 1: Clear Metro's Cache

Stop Metro completely and restart it with a clean cache:

npx expo start -c

This removes the possibility of Metro serving stale transformed files.

Step 2: Rebuild the Native Client

If you're building locally, generate a fresh native application:

npx expo run:ios

# or

npx expo run:android

This recompiles the native code using the versions currently installed in your project.

Step 3: Rebuild Your Development Build (EAS)

If you're using EAS development builds, you'll need to generate a completely new build and install it on your device.

eas build --profile development

Once the build finishes, install the new IPA or APK and launch the updated client.

Why This Fix Works

After rebuilding, both sides of the application are finally using the same version of Reanimated:

Metro serves the updated JavaScript bundle.
The native binary contains the matching JSI bindings.

Once those versions line up again, Reanimated can find the functions it expects and the crash disappears.

A Quick Note on Debugging

This was one of those bugs that initially looked like a dependency issue, then a Babel issue, then a Reanimated issue.

In reality, it was just an out-of-date native build.

Problems like this are one of the more frustrating parts of React Native because the error message rarely points to the actual cause. It's easy to spend hours looking at package versions when the real fix is simply rebuilding the native client.

After spending enough evenings digging through stack traces, GitHub issues, and old forum threads, I ended up building a small tool called Fix My Error.

You paste in the error output, and it helps narrow down likely causes and fixes without having to bounce between ten different tabs looking for someone who hit the same problem three years ago.

For this particular error, though, the fix turned out to be much simpler than I expected: clear Metro, rebuild the native client, and make sure your JavaScript bundle and native runtime are actually running the same version.

How to Fix: "Namespace not specified" Gradle 8 Error in React Native & Expo

Thu, 09 Jul 2026 12:45:41 +0000

Fixing the "Namespace Not Specified" Error in React Native and Expo Android Builds

If you recently upgraded a project to React Native 0.73+ or bumped your Expo SDK to version 50+, you may have run into an Android build error that looks something like this:

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring project ':react-native-some-old-library'.

> Namespace not specified for group 'react-native-some-old-library'
  and version '1.0.0' as per the Android Gradle Plugin 8.0+ guidelines.

At first glance, it looks like something is wrong with your app. In most cases, it isn't.

The error is usually coming from an older dependency inside node_modules.

Here's what's actually causing it and how to fix it properly.

The Root Cause

Before Android Gradle Plugin (AGP) 8.0, Android libraries could define their package name inside AndroidManifest.xml.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.someoldlibrary">

Starting with AGP 8.0, that is no longer enough.

Every Android module is now expected to define a namespace inside its build.gradle file.

When you upgrade React Native or Expo, your Android tooling gets upgraded as well. The problem is that many older React Native libraries haven't been updated to follow the new requirement.

As soon as Gradle encounters one of those libraries, it stops during configuration and the build fails.

This started showing up much more frequently after Expo SDK 50 and newer React Native releases adopted newer Android tooling.

Before You Change Anything

Look closely at the error message.

Most of the time you'll see something like:

A problem occurred configuring project ':react-native-some-old-library'

That project name is usually the library causing the issue.

A common mistake is to start editing your app's own Gradle files. In most cases, the problem is actually inside the dependency listed in the error.

The Fix: Use patch-package

Since the problem comes from a third-party library, editing files directly inside node_modules isn't a real fix.

The next time you run npm install, your changes will be overwritten.

Instead, make the change once and save it using patch-package.

Step 1: Find the Package Name

Navigate to the library's manifest file:

node_modules/react-native-some-old-library/android/src/main/AndroidManifest.xml

Look for the package attribute:

<manifest
    package="com.someoldlibrary">

Copy that value.

You'll use it as the namespace in the next step.

Step 2: Add the Missing Namespace

Open:

node_modules/react-native-some-old-library/android/build.gradle

Find the android {} block and add the namespace at the top:

android {
    namespace "com.someoldlibrary"

    compileSdkVersion safeExtGet('compileSdkVersion', 34)

    defaultConfig {
        minSdkVersion safeExtGet('minSdkVersion', 21)
        targetSdkVersion safeExtGet('targetSdkVersion', 34)
    }

    // ...
}

Make sure the namespace exactly matches the package name from the manifest.

Step 3: Generate a Patch

From your project root, run:

npx patch-package react-native-some-old-library

This creates a file inside a new patches directory containing the modification you just made.

Commit that file to Git.

Step 4: Apply the Patch Automatically

Open package.json and add a postinstall script:

{
  "scripts": {
    "start": "expo start",
    "android": "expo run:android",
    "ios": "expo run:ios",
    "postinstall": "patch-package"
  }
}

Now whenever someone runs npm install—whether it's you, another developer, CI, or EAS Build—the patch gets applied automatically.

That's It

Clear any caches if needed and run your Android build again.

The build should now complete normally.

More importantly, you won't have to keep making the same edit every time node_modules gets reinstalled.

If you're working with older React Native dependencies, this is usually the cleanest way to handle AGP 8 namespace issues without waiting for the library maintainer to release an update.

How to Fix Expo's Cryptic Upgrade Trap: Android Resource Linking Failed (splashscreen_logo not found

Sat, 20 Jun 2026 12:10:50 +0000

How to Fix "resource drawable/splashscreen_logo not found" After an Expo SDK Upgrade

Upgrading your Expo SDK version to keep up with the latest App Store and Google Play requirements is usually a smooth process—until Gradle decides to punch you in the face with a cryptic asset compilation error.

If you just kicked off an Android build or ran a prebuild, and your terminal suddenly spit out a wall of red text looking exactly like this, you are not alone:

A failure occurred while executing com.android.build.gradle.internal.res.LinkApplicationAndroidResourcesTask$TaskAction
> Android resource linking failed
error: resource drawable/splashscreen_logo (aka com.yourcompany.app:drawable/splashscreen_logo) not found.

The worst part about this error is that it doesn't give you a file name, a line number, or any mention of Expo.

It just drops a native Android resource compilation failure and leaves you to figure out the rest.

Let's break down exactly why this happens during Expo upgrades and how to fix it in two minutes flat.

Why This Happens: The Missing Asset Trap

This issue is a classic side effect of how newer Expo SDK versions handle Continuous Native Generation (CNG) via the expo-splash-screen plugin.

In older versions of Expo, if you only wanted a solid background color for your splash screen, you could get away with just defining backgroundColor in your config and skipping the logo image entirely.

The native generator would handle it gracefully.

However, in newer Expo SDK configurations, the prebuild engine has become much more strict.

If the image property is missing from your splash screen configuration, the Expo generator completely skips creating the native Android XML drawable references for the logo.

When the Android Gradle plugin compiles the app layer, it looks into the generated styles for the splash screen layout, tries to link the splashscreen_logo asset, finds a blank void, and crashes the entire build.

How to Fix It

To resolve this, we need to explicitly force the Expo prebuild engine to map a valid drawable resource so Gradle stops complaining.

Step 1: Update Your App Configuration

Open your app.json (or app.config.js) file and locate your plugins array.

Make sure the expo-splash-screen plugin block contains both a background color and an explicit path to a fallback image asset.

Even if you don't actually want a logo on your splash screen, you need to provide a placeholder image (like a tiny 1x1 transparent or solid pixel matching your background color) to satisfy the native compiler.

"plugins": [
  [
    "expo-splash-screen",
    {
      "backgroundColor": "#ffffff",
      "image": "./assets/splash-icon.png"
    }
  ]
]

Step 2: Clear and Regenerate Native Directories

Because native Android build directories heavily cache old configurations, simply changing app.json isn't always enough to clear out the corrupted Gradle state.

Run the following commands in your terminal to wipe the slate clean and force a fresh native generation:

# If you are testing local native builds:
npx expo prebuild --clean

# Or if you are running a fresh release compilation:
npx expo run:android --variant release --no-build-cache

Once the prebuild engine re-runs with the new configuration, it will successfully generate the splashscreen_logo.xml drawable file inside your native directories, and Gradle will breeze right past the linking stage.

Interactive Reference & Live Fix

If you want to view a fully verified configuration block or run this code through an interactive debugger to make sure your syntax matches up perfectly, you can check out the public resolution ledger here:

Fix My Error

Final Thoughts

Native Android build failures often look terrifying because the error message points to generated resources rather than the actual configuration mistake.

In this case, the root cause is usually a missing splash screen image definition after upgrading to a newer Expo SDK version.

Once you add a valid image path and regenerate your native directories, the build should proceed normally.

Have you run into any other weird compilation errors while moving your project up to the latest Expo SDK?

Drop them in the comments below and let's unblock them.

Debugging frontend crash and handling circular dependency

Thu, 11 Jun 2026 01:17:15 +0000

A production crash in NeetoCRM was caused by a circular dependency between commons/constants.js and commons/utils.jsx. In development, Vite's native ES module evaluation order masked the issue, but esbuild's production bundling exposed it by placing constants.js code before createColumn was initialized. The fix involved moving createColumn into a standalone module to break the cycle. The post also covers two related findings: how session replay tools like rrweb wrap console methods and mislead DevTools attribution, and how Honeybadger missed the crash entirely because it was initialized inside the React tree rather than before the App chunk loaded. The solution moves Honeybadger.configure() to application.js before mount() runs, ensuring startup failures are captured.

🚀 Debuggix – AI That Fixes Your Code in 60 Seconds

Wed, 10 Jun 2026 14:28:52 +0000

Tired of spending hours debugging your code? Debuggix uses 9 powerful security and error-checking engines to automatically detect and fix issues in your code in under a minute. Simply paste your code, let the AI analyze it, and get instant fixes while ensuring security and reliability.

Key Features:

Multi-language support – Works with major programming languages.
Security-focused – 9 engines check for vulnerabilities.
Time-saving – Fix bugs in 60 seconds.
AI-powered – Smart suggestions and automated corrections.

Perfect for developers, freelancers, and teams who want to write secure, bug-free code faster.

Check it out: Debuggix

AI #CodeAutomation #Debugging #DeveloperTools #Productivity #Security

How to Fix Xcode C++ Compiler Errors in React Native (Yoga / glog / constexpr)

Sat, 06 Jun 2026 09:39:12 +0000

You just upgraded your local development environment, updated Xcode, or bumped a minor patch version in your React Native project. You open your terminal, run your standard iOS build command, and instead of a clean bundling process, the terminal throws a massive wall of raw C++ compiler text at you.

The error logs likely point to internal framework files like Yoga.cpp, glog, or the fmt library, screaming about constexpr or consteval issues, or complaining that a specific language standard identifier is missing.

This is one of the single most frustrating traps in mobile development. Your JavaScript is perfect. Your React components are clean. But your entire build is dead because an underlying C++ compilation standard is fighting your new Xcode tooling.

Why This Happens to JavaScript Developers

React Native relies heavily on a core C++ layout engine called Yoga under the hood. When Apple updates Xcode, they also update the underlying compiler tools (Clang) and shift the default C++ language dialect standard forward (for example, enforcing strict C++20 or C++23 rules).

If an older version of a library in your node_modules uses a syntax decoration that the new compiler now considers illegal or deprecated, the native compilation step fails instantly. Because most mobile developers do not actively write pure C++, looking at a raw Clang compiler failure feels like looking at alien code.

Nuking DerivedData or running pod install twenty times will not change the fact that the compiler rules have changed.

The Solution: Force the C++ Language Standard Backwards

Instead of attempting to manually modify source code deep inside your native node_modules dependencies (which will just get overwritten the next time you install packages), you can use a CocoaPods post-install hook to force the compiler to accept the specific language dialect your dependencies need to pass the check.

Open the Podfile located inside your project's native ios directory. Scroll down to the bottom where your post_install loop lives, and inject this compiler flag override block:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      # Force the compiler to use the stable C++17 standard for all sub-dependencies
      config.build_settings['CLANG_CXX_LANGUAGE_STANDARD'] = 'c++17'
    end
  end
end

By adding this configuration script, CocoaPods will automatically modify the native build files for every single sub-dependency when you run your installation pipeline, forcing Xcode to evaluate the underlying C++ libraries under a compatible standard framework.

Clear the Native Caches and Rebuild

Once the project configurations are updated, you must completely destroy the old build artifacts that were compiled under the conflicting settings, or Xcode will continue to throw the same syntax exception.

Run this quick command chain in your project terminal to wipe the native cache layers and execute a clean compilation:

# Clear Xcode's local compilation cache
rm -rf ~/Library/Developer/Xcode/DerivedData

# Re-evaluate the Podfile with the new compiler hook
cd ios
pod install --repo-update

# Return to root and boot the iOS simulator
cd ..
npx react-native run-ios

As soon as the native build pipelines evaluate your sub-dependencies through the consistent compiler standard, the cryptic layout exceptions will vanish and your bundle will build cleanly.

How to fix 'RNGestureHandlerModule could not be found' in React Native & Expo

Sun, 31 May 2026 17:13:39 +0000

Ever run a fresh compilation on a React Native project, change absolutely nothing, and watch your simulator immediately crash with this terminal masterpiece?

ERROR Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'RNGestureHandlerModule' could not be found. Verify that your native modules are linked correctly.

It usually happens right after initializing a navigation library or an interactive UI package that relies on react-native-gesture-handler under the hood.

If you are stuck looking at this stack trace right now, here is exactly why it is broken and how to resolve it in two minutes.

The Root Cause: JavaScript Is Floating Alone

When you run standard web frameworks, importing a package updates your node dependency tree and just works. In React Native, complex packages have two distinct layers:

The JavaScript API layer (the code you write in your editor).
The Native Architecture layer (the actual Swift/Objective-C or Java/Kotlin binaries compiled into the iOS/Android app wrappers).

This error occurs because your Metro bundler successfully loaded the new JavaScript components, but your local native build directory has no idea those new binaries exist yet. The framework is trying to call native routines that simply weren't compiled during your last native build cycle.

How to Fix It

1. For Expo Development Builds (Most Common)

If you are using Expo and running prebuilds, simply running a standard terminal refresh won't pass the native binary threshold. You need to trigger a full native binary compilation sequence to force Expo to link the missing native modules folder structure into your binary targets:

# For Android simulators/devices:
npx expo run:android

# For iOS simulators/devices:
npx expo run:ios

2. For Bare React Native Projects

If you are managing your own native folders directly, you need to clear your build cache and explicitly map the cocoapods dependency layer for iOS:

# Clear out your local build artifacts
watchman watch-del-all && rm -rf node_modules && npm install

# Re-link native iOS libraries
cd ios && pod install && cd ..

# Rebuild your active runtime binary
npx react-native run-ios

Once the compilation pipeline finishes creating the new application layout, the native module registration bridge hooks up properly, and your navigation screens will load without a hitch.

Hopefully, this saves you from losing an hour down a stack trace rabbit hole today.

If you run into other cryptic Expo or React Native native errors while building, I put together a quick web diagnostic tool called FixMyError.dev that contextually reverse-engineers stack traces into human-readable resolutions like this one. There's a free live sandbox on the landing page if you just want to test it out next time your terminal starts throwing errors.

Back to building!

The Bash $PATH Debugger I Run Whenever I Get "Command Not Found"

Fri, 08 May 2026 18:09:24 +0000

Every experienced Linux user has been there: you install something, or move directories around, and suddenly command not found appears for tools you know are installed.

You check which, type, echo $PATH, and still waste 10-20 minutes hunting down the issue. I've done it more times than I care to admit — especially after fresh server setups or when cleaning up dotfiles.

That's why I built (and now constantly use) a Bash $PATH Debugger.

Paste your $PATH and get instant diagnosis

Here's how it works in practice:

Copy your current PATH: echo $PATH
Paste it into the tool
Get a full report + fixed version in seconds

Try it here: Bash $PATH Debugger

What the tool does

The debugger takes your raw $PATH string and analyzes every directory with these checks:

Existence: Does the directory actually exist on the filesystem?
Duplicates: Are you wasting lookup time with repeated entries?
Permissions: Are any directories missing execute permissions for your user?
Order: Shows the exact search priority (first match wins)
Clean output: Generates a cleaned, deduplicated export PATH=... line ready for .bashrc or .profile

It even highlights common problems like missing ~/.local/bin, collapsed entries after moves, or directories that exist but aren't in your current session.

Why this tool saves so much time

"command not found" (exit code 127) is one of the most searched Bash errors online. Yet most resources just tell you to export PATH=... manually without diagnosing why it broke.

This tool does the diagnosis for you. It's especially powerful on fresh VPS setups, after migrating user accounts, or when working with Docker/container environments where PATH behaves differently.

Real-world use cases

After a apt install or brew install that doesn't add itself to PATH properly
Debugging why a script works in one terminal but not another
Cleaning up an overloaded PATH that accumulated junk over years
Preparing a clean minimal PATH for production servers

Pro tip: Test on a clean VPS

One of my favorite workflows is spinning up a fresh $4-5/mo VPS, installing my usual tools, running them through the debugger, and copying the optimized PATH into my base server image.

Common variations & advanced usage

The tool also supports:

Relative path expansion
Handling of ~ and environment variables in PATH entries
Export formats for different shells (bash, zsh, fish compatibility notes)

Full interactive tool with live diagnosis, cleaned PATH generator, and detailed explanations:
https://bashsnippets.xyz/tools/path-debugger.html

Paste your PATH. Fix the problem. Move on.

Optimizing Flutter Apps: A Deep Dive into Dart DevTools

Fri, 08 May 2026 09:59:05 +0000

Most Flutter developers know how to build apps. Far fewer know how to build fast ones. The gap between a good app and a great one often isn't in the features. It's in the frames dropped, the memory leaked, and the milliseconds lost.

Dart DevTools is your toolkit for closing that gap. This guide walks through each of its major panels, what they're good for, and how to actually use them on a real app.

Before you start: Always profile in profile mode, not debug mode. Debug mode runs with extra assertions and overhead that will skew every reading you take.
flutter run --profile

The Flutter Inspector gives you a live, interactive view of your widget tree. Think of it as browser DevTools, but for your UI hierarchy. Here are the four toggles you'll use most.

Slow Animations

Complex animations can be impossible to debug at full speed. Toggling Slow Animations in the Inspector, or setting this in code, drops them to 20% speed so you can catch glitches frame by frame.

import 'package:flutter/scheduler.dart';

void main() {
  timeDilation = 5.0; // 5× slower
  runApp(const MyApp());
}

Guidelines & Baselines

Enables visual overlays that draw:

Scroll direction indicators on scrollable widgets
Widget boundaries (render object outlines)
Text baselines to catch misaligned typography

This is particularly useful when you suspect a layout issue but cannot pinpoint which widget is the culprit.

Highlight Repaints

Every time a widget repaints, it flashes a continuous stream of color. If your entire screen is flashing because a small loading spinner is animating, you have a problem.

I once traced a scrolling jank issue to a blinking typing indicator that was forcing an entire chat screen to repaint every frame.

The fix is a RepaintBoundary. It tells Flutter to isolate that subtree into its own render layer, so its repaints do not cascade upward.

RepaintBoundary(
  child: MyAnimatedWidget(),
)

Use this around widgets that animate independently, such as loaders, progress bars, and live counters.

Highlight Oversized Images

If an image is decoded at 2000×2000px but displayed at 100×100px, you're wasting memory on 39,900 pixels that will never be seen. This toggle shows them as negative and rotates them as shown in the image

The fix is straightforward. Constrain decoding at the source:

Image.network(
  'https://example.com/large-image.jpg',
  cacheWidth: 200,
  cacheHeight: 200,
)

Flutter will downsample the image before caching it, significantly reducing memory pressure on image-heavy screens.

2. App Size Analysis — Know What You're Shipping

A bloated app takes longer to download, longer to install, and gives a worse first impression before the user has even launched it. The --analyze-size flag gives you a breakdown of exactly what's eating into your bundle.

For Android

flutter build apk --analyze-size

For iOS

flutter build ipa --analyze-size

This outputs a JSON file that you import directly into DevTools. Once loaded, you get two views:

Dominator Tree

Shows which packages are responsible for the largest chunks of your app size. If a utility package you barely use is claiming 3MB, it is worth reconsidering.

Call Graph

Maps how your dependencies import each other. This is how you find transitive dependencies you did not know you had. A package pulls another package, which pulls another, each silently adding weight.

Size is a feature.

3. Performance & Jank Tracking — Chasing Smooth Frames

The target is 60 frames per second. That gives each frame exactly 16.6 milliseconds to build and render. Any frame that exceeds this budget is called a jank, and users feel every one of them, even if they cannot name what's wrong.

The Performance tab lets you:

Record a session of real app interactions
View a flame chart of frame build times
Click into expensive frames to see exactly which build, layout, or paint call consumed the most time

The key is to record specific interactions rather than letting it run indefinitely. Navigate to the screen you suspect is slow, hit record, reproduce the issue, then stop. A focused recording is far easier to read than five minutes of noise.

Look for the red frames in the timeline. Those are your jank frames. Drill into them, and you'll usually find one of three things:

An expensive build() method
An unnecessary full-tree rebuild
A synchronous operation blocking the main thread

Heavy JSON parsing, large computations, or image processing should not run on the UI isolate. Move them to another isolate using compute() whenever possible.

final result = await compute(parseLargeJson, jsonString);

4. Network & CPU Profiling — Under the Hood

Network Tab

If you've ever tried to debug an API issue by reading through a wall of flutter: {...} in the debug console, the Network tab will feel like a revelation.

It captures every HTTP request your app makes and displays:

Full request and response headers
Response body and status codes
Request timing and duration

No more print-statement archaeology. You can see at a glance if a request is failing, slow, or returning unexpected data.

CPU Profiler

The CPU Profiler records a flame chart of method calls while your app runs. When something feels sluggish but the Performance tab does not show obvious jank, this is where you look.

It is especially good for catching:

Expensive operations accidentally running on the main isolate
Framework callbacks firing more often than expected
Third-party packages with surprisingly heavy footprints

5. Memory & Debugger — Stability Under Pressure

Memory Tab

Memory leaks are silent killers. Your app might run perfectly in testing and degrade over time in production as memory accumulates and is never released.

The most common culprit in Flutter is forgetting to dispose() objects that hold onto resources.

class MyWidget extends StatefulWidget { ... }

class _MyWidgetState extends State<MyWidget>
    with SingleTickerProviderStateMixin {

  late AnimationController _controller;

  @override
  void initState() {
    super.initState();
    _controller = AnimationController(
      vsync: this,
      duration: const Duration(seconds: 1),
    );
  }

  @override
  void dispose() {
    _controller.dispose();
    super.dispose();
  }
}

The Memory tab shows a real-time chart of heap allocation. If memory climbs steadily as you navigate through your app and never comes back down, you likely have a leak.

Reproduce the navigation repeatedly and watch the graph. A healthy app's memory should stabilize over time.

Debugger

The built-in debugger supports:

Breakpoints
Step-through execution
Variable inspection

All without leaving DevTools.

This is useful for tracking down logic bugs that only appear in certain states, or for understanding a complex call chain without littering your codebase with print() calls.

Key Principles to Take Away

Profile Mode Is Non-Negotiable

Debug mode adds overhead that makes everything look slower than it is. Measure performance in profile mode, always.

Do Not Optimize Blindly

Reach for DevTools when you observe a real problem:

A user complaint
A visible stutter
A reported crash

Premature optimization creates complexity without measurable benefit.

Older Devices Are Your Benchmark

An app that runs smoothly on a flagship device might choke on a three-year-old mid-range phone. Test on the weakest hardware your users are likely to have.

Dart DevTools removes the guesswork from Flutter performance.

Each panel answers a specific category of question:

What's rendering
What's too big
What's too slow
What's leaking

Use them together, and you'll spend less time wondering why your app feels sluggish and more time fixing it.

Thanks to Aswin Gopinathan for this wonderful workshop, from which I got the knowledge for this blog. Do check it out on Youtube