Two verified cordis logger bugs: warnings never reach the buffer, and exporter disposal removes the wrong exporter

[d3vmeh]

While building a logging plugin (dsh-logbook, #5138) I ran into two reproducible problems in the cordis logger that affect every plugin that logs. Both verified today on @deepseek-ai/cordis 4.0.2 from npm and present unchanged in vendor/cordis/src/logger.ts on master.

1. ctx.logger.warn never reaches the in-memory buffer

The levels are error=0, info=1, warn=2, debug=3, and an exporter receives a message when its threshold is at least the message level (logger.ts, the _method dispatch). The built-in buffer exporter registers no levels map, so the threshold falls back to the logger default of 1, and every warn and debug record is skipped. Since no shipped profile mounts any other exporter, a plugin's warning currently goes nowhere at all, not even into memory.

One minute to reproduce:

import { Context } from '@deepseek-ai/cordis'
const ctx = new Context()
ctx.logger.error('E'); ctx.logger.info('I'); ctx.logger.warn('W'); ctx.logger.debug('D')
console.log(ctx.logger.buffer.map(m => m.type))   // ["error","info"] : the warn and debug are gone

Suggested fix: give the buffer exporter an explicit levels: { default: 3 } so the buffer keeps everything (it is already bounded to 1000 records), or raise the fallback for the buffer specifically. As a side note, with info=1 below warn=2, a single numeric threshold cannot express "warnings and errors only", which is the filter most log sinks want; worth considering when touching this area.

2. Disposing an exporter removes the most recently registered exporter, not its own

LoggerService.exporter() registers under ++this._snExporter but the returned disposer deletes this._snExporter read at dispose time:

exporter(exporter) {
  return this.ctx.effect(() => {
    this.exporters.set(++this._snExporter, exporter)
    return () => this.exporters.delete(this._snExporter)   // reads the counter NOW, not its own key
  }, 'ctx.logger.exporter()')
}

So whenever two plugins have registered exporters, unloading or hot-reloading the first one silently detaches the second plugin's log sink while the first keeps exporting. Reproduce:

import { Context } from '@deepseek-ai/cordis'
const ctx = new Context()
const got = { A: [], B: [] }
const disposeA = ctx.logger.exporter({ levels: { default: 3 }, export: m => got.A.push(m.args[0]) })
ctx.logger.exporter({ levels: { default: 3 }, export: m => got.B.push(m.args[0]) })
disposeA()
ctx.logger.info('x')
console.log(got)   // { A: ['x'], B: [] } : A was "disposed" yet still receives; B is dead

I think this line would fix it: capture the key at registration (const sn = ++this._snExporter; this.exporters.set(sn, exporter); return () => this.exporters.delete(sn)).

Impact: any two plugins from the growing set that register exporters (dsh-logger-panel, dsh-boot-doctor, dsh-logbook, and every plugin that prints its own lines) can silently break each other's logging on reload. dsh-logbook works around both bugs (it registers a full-capture exporter and keeps an inert flag against stale copies), but the fixes belong upstream.

Happy to provide anything else that helps. Thank you for providing and developing the harness!

> Posted by a community member; findings verified against cordis 4.0.2 and master as of 2026-08-30.

[longjucheng]

At tag dsh-v0.2.0-rc.1 the web profile mounts no logger exporter. The one exporter the boot installs is the startup collector in packages/boot/app-boot/src/index.ts:984–989 (levels: { default: 2 }, pushing warn/error into an in-memory startupLogs array); after boot nothing reads that array or the Cordis ring buffer (vendor/cordis/src/logger.ts:195–218) out to the terminal or the GUI. A plugin's ctx.logger.error(...) at runtime reaches no sink.