DEV Community: Hala

How to Fix Image Upload Failures & 404 Errors in React Native + Express/Multer

Hala — Fri, 24 Jul 2026 12:07:36 +0000

Uploading images from a React Native (Expo) client to a Node.js/Express backend using Multer is a common task, but it often comes with two frustrating issues:

TypeError: Network request failed during the upload process.
404 Not Found warnings when trying to render uploaded images in the mobile app.

Here is a breakdown of why these errors happen and how to resolve them cleanly on both the backend and client side.

The Error Logs

1. Upload Phase Error (React Native Console)

ERROR Upload error: [TypeError: Network request failed]

2. Asset Rendering Phase Warning (Expo / LogBox)

WARN Unexpected HTTP code Response{protocol=http/1.1, code=404, message=Not Found, url=http://192.168.8.101:8000/uploads/1784893610816-edeedac9.jpeg}

Root Cause Analysis

Problem 1: Unhandled Missing Upload Directory (`ENOENT`)

When using multer.diskStorage, you specify a target directory like public/uploads. Multer does not create missing folders automatically. If that folder does not exist on your server when an upload request hits the endpoint, Node.js throws an ENOENT exception, abruptly closing the socket connection. From the React Native side, this manifests as TypeError: Network request failed.

Problem 2: Incorrect Static File Route Prefix

Using app.use(express.static("public")) in Express serves the contents of the public folder directly from the root path (http://IP:PORT/filename.jpg). If your client tries to fetch http://IP:PORT/uploads/filename.jpg, Express cannot map the path correctly and returns a 404 Not Found.

Problem 3: Android File URI Formatting

Local image URIs retrieved on Android devices often require explicit formatting (uri, name, type) inside FormData to be parsed properly as a binary stream by fetch.

The Solution

1. Auto-create Directory in `multer.js`

Update your Multer configuration to check for and create the target directory dynamically using the standard fs module:

import multer from "multer";
import fs from "fs";
import path from "path";

const uploadDir = "public/uploads";

if (!fs.existsSync(uploadDir)) {
  fs.mkdirSync(uploadDir, { recursive: true });
}

const storage = multer.diskStorage({
  destination: (req, file, cb) => {
    cb(null, uploadDir);
  },
  filename: (req, file, cb) => {
    const ext = path.extname(file.originalname) || ".jpg";
    cb(null, `${Date.now()}-${Math.round(Math.random() * 1e9)}${ext}`);
  },
});

const upload = multer({ storage });

export default upload;

2. Map Static Route Correctly in `server.js`

Explicitly map requests containing the /uploads prefix to the physical public/uploads directory on disk:

import express from "express";

const app = express();

app.use("/uploads", express.static("public/uploads"));

3. Handle Client-Side Uploads in React Native (`functions.js`)

Format the image payload cleanly inside FormData before making the network call:

import { Platform } from "react-native";
import { API_URL } from "@env";

export async function uploadImage(token, localUri) {
  try {
    const filename = localUri.split("/").pop() || "profile.jpg";
    const match = /\.(\w+)$/.exec(filename);
    const type = match ? `image/${match[1]}` : "image/jpeg";

    const fileUri = Platform.OS === "android" ? localUri : localUri.replace("file://", "");

    const formData = new FormData();
    formData.append("profilePicture", {
      uri: fileUri,
      name: filename,
      type: type,
    });

    const authHeader = token?.startsWith("Bearer ") ? token : `Bearer ${token}`;

    const response = await fetch(`${API_URL}/user/profile-picture`, {
      method: "PUT",
      headers: {
        Authorization: authHeader,
        Accept: "application/json",
      },
      body: formData,
    });

    const data = await response.json();

    if (!response.ok) {
      throw new Error(data.error || data.message || `Server Error: ${response.status}`);
    }

    return data;
  } catch (error) {
    console.error("Upload error:", error);
    throw error;
  }
}

Verification & Results

Applying these updates addresses the issue on both ends:

The backend responds with HTTP status 200 OK on image upload requests.
MongoDB stores the reachable absolute URL string.
Both iOS and Android clients render the updated profile image without broken image icons or caching issues.

Conclusion

When building mobile apps with React Native and Node.js, ensure your server dynamically verifies target upload paths at runtime, and double-check that Express static route configurations mirror the URL paths requested by the frontend client.

Fixing “Please update Expo Go” error (even when it’s already updated)

Hala — Tue, 02 Jun 2026 01:49:46 +0000

While developing a React Native app using Expo, I ran into a really confusing issue.

Every time I tried to run my project, the app would open normally but immediately show this message inside the app:

“Please update Expo Go to the latest version from Google Play Store”

The strange part?
My Expo Go was already updated to the latest version from the Google Play Store.

I double-checked multiple times, uninstalled and reinstalled it, but the error still kept showing.

Environment
React Native (Expo)

Expo SDK (latest at the time of writing)

Android (Google Play Store version of Expo Go)

No errors in terminal

What I tried

Before finding the actual fix, I tried the usual debugging steps:

Reinstalling Expo Go from Google Play Store

Logging out and logging back into Expo

Reconnecting the project

Restarting Metro bundler

Clearing cache and node modules

Rebuilding the project

Nothing worked ❌

Everything looked fine… except the error inside the app.

The real issue

The problem wasn’t in my code or Expo setup.

It was a version mismatch between the Play Store Expo Go build and the required SDK version of my project.

Even though the app showed as “updated”, it was still not compatible with my project’s Expo SDK version.

The solution

Instead of relying on the Play Store version, I installed the latest Expo Go build manually from the official source.

After installing it manually:

The app launched successfully

The error disappeared immediately

Everything worked as expected

Key takeaway

If you ever see this message:

“Please update Expo Go…”

even when your app is already updated from the Play Store:

👉 Don’t assume it’s actually up to date
👉 Try installing the latest version manually from the official Expo releases instead

It saved me hours of confusion and debugging.

Final thoughts

This was one of those annoying issues where everything looks correct, but the problem is actually in version alignment between tools rather than your code.

Hopefully this helps someone avoid the same headache 🙂

How Windows Caused a Fatal “typeof” Error in Expo EAS Build — And Why Linux Solved It

Hala — Mon, 23 Mar 2026 03:26:45 +0000

Introduction

I recently faced one of the strangest and most frustrating technical issues in my development journey. My mobile application was working perfectly during development, but everything broke when I tried to build the production Android version.

What made the situation worse was that the error appeared to be unrelated to my code. After several days of troubleshooting, the solution turned out to be something I never expected: the operating system itself.

This article documents the full technical journey in hopes that it helps any developer facing a similar issue.

The Fatal Error

The project ran normally in development mode using Expo. However, when attempting to build the Android production version using EAS Build:

eas build --platform android --profile production

The process suddenly stopped and repeatedly produced the following error:

SyntaxError: Unexpected token 'typeof'
at Object.compileFunction (node:vm:360:18)
at wrapSafe (node:internal/modules/cjs/loader:1055:15)

The error appeared dozens of times and prevented the build from completing.

Engineering Analysis

This was not a logic error in the application code.

Instead, it was an Interpreter Compatibility Conflict between the Node.js engine and the Windows environment.

What was happening internally?

• EAS Build calls internal Expo dependencies such as Metro configuration packages.
• These packages rely on modern JavaScript syntax.
• On Windows, Node.js failed to parse the "typeof" keyword inside the dependency source code.
• Node interpreted it as an unexpected token, even though the syntax was valid.

In short:

«The build system failed before even reaching my application code.»

Failed Troubleshooting Attempts

I exhausted nearly every common solution used by developers on Windows environments:

1️⃣ Removing Dependencies

• Deleted "node_modules"
• Deleted "package-lock.json"
❌ Result: Failed
Reason: The issue was not corrupted packages, but how the OS interpreted them.

2️⃣ Changing Node.js Versions

• Installed multiple LTS versions
❌ Result: Failed
Reason: The conflict originated from Windows shell environment variables and system-level parsing behavior.

3️⃣ Clearing npm Cache

npm cache clean --force

❌ Result: Failed
Reason: Temporary files were not responsible.

4️⃣ Updating Build Tools

• Updated EAS CLI
• Updated Expo CLI
❌ Result: Failed
Reason: Tooling was healthy — the OS environment was not.

5️⃣ Modifying Babel & App Configurations

• Edited "babel.config.js"
• Edited "app.json"
❌ Result: Failed
Reason: The error occurred before Babel was even invoked.

The Turning Point — Migrating to Linux

At this stage, Windows became a complete roadblock.

Instead of wasting more time, I made a strategic engineering decision:

«Move the entire development environment to a Unix-based system.»

Steps Taken:

✅ Installed VirtualBox
✅ Created a virtual machine running Ubuntu Linux
✅ Installed a fresh Node.js environment
✅ Reinstalled Expo and EAS CLI
✅ Cloned the same project files without modification

The Critical Test

Inside Linux, I ran the exact same command:

eas build --platform android --profile production

Result:

✅ The error disappeared immediately
✅ The build process started successfully
✅ No code changes were required
✅ No dependency changes were required

The exact same project that failed on Windows worked flawlessly on Linux.

Technical Explanation

Linux systems are Unix-based, which aligns with the native environment used to design Node.js and Expo tooling.

This provides:

• Consistent file path handling
• Stable environment variable management
• Reliable JavaScript engine behavior
• Better compatibility with modern build systems

Meanwhile, Windows introduced hidden interpreter conflicts that disrupted dependency parsing.

Key Lesson

Sometimes the problem is not in:

❌ Your code
❌ Your libraries
❌ Your build tools

But in the execution environment itself.

When facing persistent, unexplainable build errors:

«Changing the operating system may be the most efficient solution.»

الملخص

واجهت خطأ غريب أثناء بناء نسخة الإنتاج لتطبيقي باستخدام Expo.
التطبيق كان يعمل بشكل طبيعي في التطوير، لكن أثناء تنفيذ أمر بناء الأندرويد ظهر خطأ:

SyntaxError: Unexpected token 'typeof'

بعد تجربة جميع الحلول التقليدية على نظام Windows مثل حذف المكتبات وتحديث Node وتنظيف الكاش — استمرت المشكلة.

اتضح أن السبب لم يكن في الكود، بل في تعارض بيئة Windows مع طريقة تفسير Node.js للمكتبات الحديثة.

الحل كان بالانتقال إلى نظام Linux عبر جهاز وهمي Ubuntu.

بمجرد تشغيل نفس المشروع ونفس أمر البناء على Linux:
اختفى الخطأ فوراً ونجح البناء بدون أي تعديل.

الدرس المهم:

أحياناً بيئة التشغيل نفسها هي سبب المشكلة، وتغيير النظام قد يكون الحل الجذري.