`node ace codegen` never exits when a preloaded module opens a Redis connection (warmup mode skips provider shutdown)

Aperta
#5,158 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
node.js, redis, typescript
Ambito
backend, devtools

Direzione di ricerca

Start at node ace codegen and trace its warmup boot and termination path, especially Application.terminate() and provider shutdown; the issue does not name source or test files. Reproduce with a preloaded module that opens a Redis connection, then inspect whether the process exits after Codegen files generated. Done means codegen exits successfully in this case without leaving the Redis socket open.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Package version

7.5.0

Describe the bug

Package version

  • @adonisjs/core 7.5.0
  • @adonisjs/application 9.1.0
  • @adonisjs/assembler 8.5.1
  • @adonisjs/lock 2.1.0
  • @adonisjs/limiter 3.0.1
  • @adonisjs/redis 10.0.2 (ioredis 5.11.1)
  • Node.js 24.18.0, Linux

Describe the bug

node ace codegen writes every file, prints Codegen files generated, and then never exits. Nothing is logged; it just stays open until killed.

Codegen boots the app in warmup mode. Application.terminate() skips provider shutdown in any mode other than run:

// @adonisjs/application build, terminate()
if (this.#mode === "run") await this.#providersManager.shutdown(true);
else debug_default("skipping providers shutdown in \"%s\" mode", this.#mode);

So the @adonisjs/redis provider never closes its connections. Any Redis connection opened while the routes and preloads are imported keeps the event loop alive for good.

In our app, two common patterns open that connection during warmup:

  1. Importing @adonisjs/lock/services/main. Its module body resolves the manager in app.booted:

    await app.booted(async () => {
      lockManager = await app.container.make("lock.manager");
    });
    

    lock.manager resolves every configured store (Promise.all over config.stores), so a stores.redis({}) entry connects to Redis even when it isn't the default store and no lock is ever acquired.

  2. Module-level limiter.use({...}) in a service. This creates the Redis store, and with it the connection, at import time.

Trace of the lingering handle, captured by patching Redis.prototype.connect:

at new Redis (ioredis/built/Redis.js:78:18)
at new RedisConnection (@adonisjs/redis/build/redis_manager-*.js:1206:23)
at RedisManager.connection (@adonisjs/redis/build/redis_manager-*.js:1471:146)
at Object.resolver (@adonisjs/lock/build/index.js:21:52)
at async @adonisjs/lock/build/providers/lock_provider.js:11:46
at RedisManager.connection (@adonisjs/redis/build/redis_manager-*.js:1471:146)
at Object.redis (@adonisjs/limiter/build/chunk-*.js:867:66)
at LimiterManager.use (@adonisjs/limiter/build/chunk-*.js:718:63)
at <anonymous> (app/services/segment_calculation_service.ts:13:36)

process.getActiveResourcesInfo() after codegen finishes: ["PipeWrap", "PipeWrap", "TCPSocketWrap"]. The TCPSocketWrap is the ioredis socket.

Reproduction

  1. Fresh app with @adonisjs/redis and @adonisjs/lock configured with a Redis store (stores.redis({})), and Redis running.

  2. Add a service that imports the lock service at the top level, and make it reachable from routes (e.g. through a controller that #start/routes imports):

    import lock from '@adonisjs/lock/services/main'
    export default class FooService {
      run() { return lock.createLock('foo').run(async () => {}) }
    }
    
  3. Run node ace codegen.

Expected: the process exits after Codegen files generated.
Actual: the process hangs indefinitely.

The same thing happens with a module-level const l = limiter.use({ requests: 10, duration: '1 minute' }) and a Redis limiter store.

Workaround

Gate the Redis store by mode in the config files:

// config/lock.ts
get stores() {
  return {
    redis: app.getMode() === 'run' ? stores.redis({}) : stores.memory(),
    memory: stores.memory(),
  }
},
// config/limiter.ts
get stores() {
  return {
    redis:
      app.getMode() === 'run'
        ? stores.redis({})
        : configProvider.create(async () => stores.memory({})),
    memory: stores.memory({}),
  }
},

Suggested fix

Skipping provider shutdown in warmup makes sense, but a silent hang is hard to debug. Either of these would help:

  • Have the codegen command exit explicitly once generation succeeds (it is a one-shot command, and nothing should outlive it).
  • Or, after warmup, log a warning naming the handles still open, pointing to the "don't open connections during warmup" guidance.

Separately, @adonisjs/lock could resolve stores lazily (on first use()), so that importing services/main does not connect to non-default Redis stores. Happy to open that one on the lock repo too if it's useful.

Reproduction repo

No response

Lingua principale
TypeScript
Stelle
19.2k
Fork
670
Merge medio
4g 9h
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di adonisjs/core

Tutte le issue di adonisjs/core

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.