Forem: alfanfauzy

Fixing a Weird Next.js Chunk Loading Issue Caused by Load Balancer URL Normalization

alfanfauzy — Mon, 29 Sep 2025 07:50:30 +0000

When Everything Works in Office, but Breaks in Client’s Server

Recently I faced an interesting bug when deploying a Next.js project.
On our office server, everything worked perfectly. But when the same Docker image was deployed in our client’s environment, the app broke — static chunks could not be loaded.

The Symptom

My app uses a dynamic route like:

   app/feature/[work_id]/listing/page.tsx

So Next.js generates static chunks with an encoded path like:

   /_next/static/chunks/app/feature/%5Bwork_id%5D/listing/page-xxxxx.js

But in the client’s server, I noticed requests were being made to:

   /_next/static/chunks/app/feature/%5bwork_id%5d/listing/page-xxxxx.js

Spot the difference? %5B vs %5b.
Both are technically valid encodings of [ but they are not the same string.

Why Did This Happen?

It turned out to be related to their load balancer.

URL encoding is case-insensitive (%5B = %5b = [).
But depending on the load balancer/proxy settings, hex characters can be normalized into lowercase.

In my office environment, the load balancer kept it uppercase.
In the client environment, it forced lowercase.

The Impact

Next.js expected chunks at %5Bwork_id%5D, but the request came in as %5bwork_id%5d.
Result: the chunk was not found, and the page broke.

The Fix

I added a simple middleware in Next.js to normalize the path:

   if (url.pathname.includes('%5b') || url.pathname.includes('%5d')) {
    const normalizedPath = url.pathname
      .replace(/%5b/g, '%5B')
      .replace(/%5d/g, '%5D');

    url.pathname = normalizedPath;

    return NextResponse.rewrite(url);
  }

This way, any lowercase %5b or %5d is rewritten back to uppercase, and Next.js can resolve the chunks.

🛠 Debug with cURL

After fixing the encoding in middleware (replacing %5b → %5B and %5d → %5D), I try to verify whether the chunk is correctly served.

   curl -v http://localhost:5000/_next/static/chunks/app/feature/%5bworkd_id%5d/listing/%5bdocument_id%5d/extraction/page-638a1fa4c352c07e.js

-v → verbose mode, shows both headers and body.
If the fix is correct, will should see a 200 OK response with headers like:

   HTTP/1.1 200 OK
   Content-Type: application/javascript; charset=utf-8
   Cache-Control: public, max-age=31536000, immutable

…and the body will be minified JavaScript.

If the response is 404 Not Found, the chunk is still not being resolved correctly (likely an encoding issue remains).

Lessons Learned

Bugs are not always in your code — infra can surprise you.
URL encoding might look trivial, but consistency matters when loading static chunks.
Next.js middleware can be a lifesaver for defensive fixes like this.

Have you ever faced a similar environment-only bug? I’d love to hear your story.

🎯 Don’t Forget Your Git Identity: A Must-Do When Starting a New Project

alfanfauzy — Tue, 10 Jun 2025 07:49:17 +0000

🧠 Introduction

Starting a new job or contributing to a fresh project? One of the most overlooked steps is setting up your Git config—especially your name and email. If you skip it, your commits might be misattributed, or worse, tied to the wrong identity.

In this post, I’ll walk you through the importance of Git config, what happens if you ignore it, and how to set it up correctly using --local, --global, and --system scopes.

🤔 Why Git Config Matters

Every Git commit has two important fields:

Author: your name and email address
Committer: the person who actually applied the commit (often the same)

If you don’t configure your Git identity, Git might fallback to a system default or nothing at all. This can cause:

Commits linked to the wrong email (especially if you're on a shared or borrowed machine)
Inability to link commits to your GitHub profile (leading to missing contributions)
Inconsistent commit history in team projects

🛠 Git Config Scopes: `--local` vs `--global` vs `--system`

1. --local (most specific)

Configuration is stored in the current Git repository.
Use this when you're using a different identity for a specific project.

  git config --local user.name "Alfan Fauzy"
  git config --local user.email "alfan@newcompany.com"

2. --global (user-wide)

Configuration is stored in your user directory (~/.gitconfig).
Applies to all repositories you work with unless overridden.

  git config --global user.name "Alfan Fauzy"
  git config --global user.email "alfan@personal.dev"

3. --system (least common)

Configuration is stored in the system-wide Git config file (e.g., /etc/gitconfig).
Requires sudo/admin access and applies to all users on the system.

  sudo git config --system core.editor "vim"

💡 Best Practices

Always check your Git config when starting a new job or project:

  git config --list --show-origin

Use --local for work/company-related projects, especially when using a different GitHub or GitLab account.
Avoid --system unless you're managing shared environments or tooling.

✅ Quick Setup Guide

Here’s a checklist to run before committing to a new repo:

  # Check current Git config
  git config --list --show-origin

  # Set name and email locally for the repo
  git config --local user.name "Your Name"
  git config --local user.email "your@company.com"

  # Optional: Set your preferred editor
  git config --global core.editor "code --wait"

🧵 Conclusion

Setting your Git identity might seem minor, but it's essential for maintaining clean, trackable history in your projects. Before your first commit, take a minute to check and set your Git config—it’ll save you and your team a lot of confusion down the road.

🔄 Feel free to share this with your team, especially if you're onboarding new developers!

💬 Have a Git tip to share? Drop it in the comments.

How to clone repo from Github

alfanfauzy — Mon, 13 Jun 2022 03:48:27 +0000

In the last month, my office migrate the Repositories from Gitlab to Github. I try to write this article for sharing and as my documentation.

Disclaimer : I have account in Github before and I use mac Terminal

Step 1

For the first step, I am install Github via Terminal.

brew install gh

wait the process install until see the finished installation.

Step 2

Second step, authenticated with Github Account.

gh auth login

follow the instruction until authenticate with Github Account

Step 3

Third step, create ssh-keygen to set to Github Account so we can clone the repo.

ssh-keygen

The file will create in folder /Users/yourname/.ssh/. From this step will be generate 2 file id_rsa and id_rsa.pub

Copy text file from id_rsa.pub with command

pbcopy < ~/.ssh/id_rsa.pub

Paste text info your account Github.

Last

After following all step, in the last step. I just clone the repo with command

git clone <repo link>

But, if you doing this in new computer which is the github/gitlab account didn't setting before. Check with

ssh -T git@gitlab.com

Source

https://docs.github.com/en