Cache handler is not configured yet

[cbou]

Brief Description of the Bug In my NextJS I can't manage to make the shared cache working even thought I follow the installation instructions... So I try to start from the example project and also get trouble connecting to my Redis instance.

Severity Major

Frequency of Occurrence Always

Steps to Reproduce

1. Create example project: npx create-next-app --example cache-handler-redis cache-handler-redis-app
2. Create dockerfile with redis:

   
   services:
   redis:
       image: 'redis/redis-stack:latest'
       container_name: 'my-redis'
       ports:
           - '6379:6379'
       volumes:
           - redis-data:/data

volumes: redis-data:

3. Start Redis `docker-compose up`
4. Check connection to redis `redis-cli` Should output `127.0.0.1:6379>`
5. Start building project with `NEXT_PRIVATE_DEBUG_CACHE=1 npm run build`

**Expected vs. Actual Behavior**
I would expect the cache to be saved in Redis. Instead it's saved in the local-lru as the log shows.

**Logs**

build next build

▲ Next.js 14.2.5

Creating an optimized production build ... ✓ Compiled successfully ✓ Linting and checking validity of types Collecting page data ..using custom cache handler @neshca/cache-handler is not configured yet ✓ Collecting page data Generating static pages (2/5) [= ]using custom cache handler @neshca/cache-handler is not configured yet using custom cache handler @neshca/cache-handler is not configured yet using custom cache handler @neshca/cache-handler is not configured yet Falling back to LRU handler because Redis client is not available. get from "local-lru" 4a16fa0ac7e17534c8025b4118ed4c7be14916dadfb8156a74741077df165a26 false Falling back to LRU handler because Redis client is not available. get from "local-lru" 41d286633fe4823c54b08f052b1fcc69e38bbf64c1cfca27198a6f48b8c92ed0 false Generating static pages (3/5) [== ]set to external cache store 41d286633fe4823c54b08f052b1fcc69e38bbf64c1cfca27198a6f48b8c92ed0 get from "local-lru" 41d286633fe4823c54b08f052b1fcc69e38bbf64c1cfca27198a6f48b8c92ed0 true Generating static pages (4/5) [ =]set to external cache store 4a16fa0ac7e17534c8025b4118ed4c7be14916dadfb8156a74741077df165a26 get from "local-lru" 4a16fa0ac7e17534c8025b4118ed4c7be14916dadfb8156a74741077df165a26 true ✓ Generating static pages (5/5) ✓ Collecting build traces ✓ Finalizing page optimization

Route (app) Size First Load JS ┌ ○ /_not-found 871 B 87.9 kB └ ● /[timezone] 7.54 kB 94.6 kB ├ /cet └ /gmt

• First Load JS shared by all 87 kB ├ chunks/23-636e31bc2bf9fbdc.js 31.5 kB ├ chunks/fd9d1056-62aaf4b921c84028.js 53.6 kB └ other shared chunks (total) 1.86 kB

○ (Static) prerendered as static content ● (SSG) prerendered as static HTML (uses getStaticProps)

Also starting the app is not better `NEXT_PRIVATE_DEBUG_CACHE=1 npm run start`

start next start

▲ Next.js 14.2.5

• Local: http://localhost:3000

  ✓ Starting... ✓ Ready in 196ms using custom cache handler @neshca/cache-handler is not configured yet

Environment:

• OS: MacOS 14.6
• Node.js version: v18.20.4
• @neshca/cache-handler version: 1.3.2
• next version: 14.2.5

Same with more recent versions

• OS: MacOS 14.6
• Node.js version: v20.12.1
• @neshca/cache-handler version: 1.5.1
• next version: 14.2.5

[mauroaccornero]

The example is avoiding using Redis cache during the build because of previous known issues. In addition to that you can check the documentation here: https://caching-tools.github.io/next-shared-cache/troubleshooting#method-2-debug-mode and check the final note: Note: During the build stage, it's normal to see @neshca/cache-handler is not configured yet several times.

After the build and after launching the start you should try to visit http://localhost:3000/cet or http://localhost:3000/gmt you should see a similar log in your terminal

if you click on the View RedisInsight button you should see what's inside of Redis. something like this:

let me know if this helps you, I'm using a MacOs 14.5 with node 20.13.1 with the default example.

I'm not sure if you have the same problem, but I got some issues when using docker desktop with of my Mac CPU, I resolved it when I switched to orbstack

[cbou]

Yes it works fine thanks!