Loader: config updates resolve before nested entries are reconciled

[173787247]

Summary

A config update returns before the nested entries it created have been reconciled, so await loader.update(...) resolves while the new child is still being imported.

Upstream cordis fixed exactly this in 1b7d0f2 — fix(loader): await nested reconciliation during config update (2026-09-03), which also added a test for it in packages/loader/tests/group.spec.ts. The vendored line in @deepseek-ai/cordis-plugin-loader does not have that change.

Where

cordis-plugin-loader/src/config/entry.ts, Entry._patchContext:

private _patchContext(diff: string[]) {
  this.context.waterfall('loader/patch-context', this, () => {
    Object.setPrototypeOf(this.ctx, this.parent.ctx)

    if (this.fiber?.uid && (diff.includes('config') || this.options.group)) {
      this.fiber.update(this.options.config, true)
    }
  })
}

The method is not async and neither the waterfall nor fiber.update is awaited, so all three call sites proceed immediately. Upstream made the method async and awaits both:

private async _patchContext(diff: string[]) {
  await this.context.waterfall('loader/patch-context', this, async () => {
    ...
      await this.fiber.update(this._resolveConfig(this.fiber.runtime!.callback), true)
  })
}

Reproduction

import { Context } from '@deepseek-ai/cordis'
import { Loader, Group } from '@deepseek-ai/cordis-plugin-loader'

const sleep = (ms = 0) => new Promise(r => setTimeout(r, ms))
const root = new Context()
await root.plugin(Loader)
const loader = root.loader

const foo = () => {}
const bar = () => {}
loader.modules = { foo, bar }                       // stand in for real plugins
loader.import = async (name) => { await sleep(20); return loader.modules[name] }

const group = await loader.create({
  name: '@cordisjs/plugin-group',
  group: true,
  config: [{ id: '1', name: 'foo' }],
})
await sleep(0)

await loader.update(group, {
  config: [{ id: '1', name: 'foo' }, { id: '2', name: 'bar' }],
})

// upstream: both already true / present when update() resolves
console.log('bar enabled:', !!root.registry.get(bar))
console.log('entry "2" fiber:', !!loader.store['2']?.fiber)

The 20 ms import is only there to make the gap observable; the ordering is wrong regardless of how slow the import is.

	bar enabled	entry "2" fiber
@deepseek-ai/cordis-plugin-loader (as shipped)	false	absent
upstream cordis@4.0.0-rc.10	true	present

Same probe against both, unchanged.

Why it matters here

The upstream test spells out the consequence: "without the awaited chain the update resolves while the new child is still being imported." Anything that awaits a config change and then uses the entries it just declared is racing — enabling or disabling plugins, and reloading a config file, both go through this path.

Two more upstream changes the vendored line does not have

Not part of the same defect, but they come from the same window and touch the same files, so I checked them while I was in there:

• #121 — c594d1a fix(include): reconcile file and runtime edits through a journal. cordis-plugin-include here has no journal at all, and the same commit also reordered EntryGroup.remove so the entry is unregistered before the fiber is disposed — with a comment explaining that the internal/plugin handler tells "removed by the loader" from "disposed itself" by checking whether the entry is still in the store. The vendored remove still disposes first and omits the entry.parent !== this guard the same commit added.
• #123 — c2835d8 fix(loader): resolve bare specifiers from the project. There is no resolve.ts in the vendored loader, so bare specifiers in a config file resolve against the loader rather than the project.

I have not reproduced the second one, so I am reporting it as a source-level difference rather than a confirmed defect.

Related

I have been sending fixes for some of the same files upstream — #164–#172 and #173, #174 — several with regression tests, if any of this is easier to act on with a patch attached.

[173787247]

Two more from the same audit — the vendored line is a separate track that has not taken several upstream fixes. Both below are reproduced the same way: one probe, run against the shipped package and against upstream cordis@4.0.0-rc.10, unchanged.

1. Fiber.update() drops its own failure — 2ceea23 (do not leave fiber failures unhandled, #109)

cordis/src/fiber.ts:

update(config: any, noSave = false) {
  ...
  this.context.waterfall(this, 'internal/update', config, noSave, () => {
    this.config = config
    this._error = undefined
    return this.restart()
  })
}   // no return, no catch

Upstream returns the task and marks it handled, with the reason in a comment: "a caller that drops the result cannot turn it into an unhandled rejection, while await update() still observes it."

Probe: a plugin whose apply throws on the next reload, then call update() once awaited and once dropped.

	update() returns	dropped call
as shipped	undefined — no promise to await or catch	unhandledRejection: 'boom'
upstream 4.0.0-rc.10	rejects with boom	nothing leaked

Unhandled rejections terminate the process by default, so a plugin that fails while reloading takes the host down with it. Entry.init() in the same vendored package already carries the matching .catch(() => {}) from that commit, so only the Fiber.update half is missing.

2. waterfall runs its continuations twice — 5b195b3 (guard waterfall continuations, #44)

cordis/src/events.ts has no next() called multiple times guard. A listener that calls next() twice runs the rest of the chain again instead of failing.

Probe: two listeners, the first calling next() twice, plus a terminal.

	downstream calls	thrown
as shipped	3	none
upstream 4.0.0-rc.10	2	next() called multiple times

Silent double execution is the worse half: a listener that reaches next() on two paths (an early return and a fallthrough, say) doubles whatever the rest of the chain does rather than reporting it.

Where this leaves the audit

Confirmed missing so far, all verified by probe:

upstream	what it fixes
1b7d0f2	await nested reconciliation during config update
2ceea23 (#109)	dropped Fiber.update failure becomes an unhandled rejection
5b195b3 (#44)	waterfall continuation run twice

Still source-level only, not reproduced: c594d1a (#121, include journal + the EntryGroup.remove order and guard) and c2835d8 (#123, bare specifier resolution).

I have the probes for the three above as standalone scripts and can paste any of them if that helps.

[173787247]

Three more, same method — one probe per item, run against the shipped package and upstream cordis@4.0.0-rc.10 unchanged.

3. Concurrent interval() reads never settle — cb77029 (settle concurrent interval reads in order, #53)

cordis-plugin-timer/src/index.ts keeps a single slot:

let nextTask: PromiseWithResolvers<IteratorResult<void>> | undefined
...
next: () => {
  if (!done) return (nextTask = Promise.withResolvers()).promise

A second next() before a tick overwrites the first, whose promise is then never settled. Upstream holds an array and settles every waiter in order.

const it = root.interval(40)
await Promise.all([it.next(), it.next()])   // resolves here, hangs there

waiters	as shipped	upstream
2	times out	both resolve
3	times out	all resolve

for await over ctx.interval(delay) in two places at once is the shape that stalls — one of them never sees a tick.

4. An event named after an Object.prototype member throws — 1c1a10e (dispatch symbol and prototype-named events, #51)

cordis/src/events.ts initialises the hook table with {} where upstream uses Object.create(null):

_hooks: Record<keyof any, Hook[]> = {}
...
const hooks = this._hooks[name] ||= []

this._hooks['toString'] finds the inherited Object.prototype.toString instead of undefined, so the ||= never fires and hooks is a function:

ctx.on('toString', () => {})   →  TypeError: hooks[method] is not a function

Upstream registers it normally. Same for constructor, valueOf, hasOwnProperty.

5. The logger's bounded buffer is replaced, not truncated — fd96b0a (logger exporter dispose, #36)

self.buffer.push(message)
if (self.buffer.length > self.bufferSize) {
  self.buffer = self.buffer.slice(-self.bufferSize)
}

Assigning a new array leaves every existing holder of ctx.logger.buffer pointing at the old one, which keeps growing without bound. Upstream truncates in place; the test it added is named "keeps the bounded buffer in place and chronological".

const held = ctx.logger.buffer     // what a log panel would hold
ctx.logger.bufferSize = 2
for (let i = 0; i < 6; i++) ctx.logger.info('msg' + i)

held.length                 // 3 and climbing, vs 2 upstream
ctx.logger.buffer.length    // 2 either way

The same commit's exporter-dispose half is present here already, in a ctx.effect form, so only the buffer half is missing.

Running list

upstream	what it fixes	verified
1b7d0f2	await nested reconciliation during config update	probe
2ceea23 (#109)	dropped Fiber.update failure becomes an unhandled rejection	probe
5b195b3 (#44)	waterfall continuation run twice	probe
cb77029 (#53)	concurrent interval() reads never settle	probe
1c1a10e (#51)	Object.prototype-named events throw on registration	probe
fd96b0a (#36)	logger buffer replaced instead of truncated	probe

Source-level only, not reproduced: c594d1a (#121) and c2835d8 (#123). Still checking 8abd903 (#35), be7d36e (#37), 4cfd19a and 752dbee (#40) — those four look like the same features implemented differently rather than omissions, and I would rather confirm that than report them as missing.

[173787247]

Closing out the four I said I was still checking — the outcome is better than the raw diff suggested.

Present, just implemented differently — the shadow/traceable machinery is all here under its own shape (noShadow, applyTraceable, createShadowMethod, createShadow, getTraceable are all in cordis/src/utils.ts):

• be7d36e (Windows 11 下 Firefox 中"添加工作区"的原生目录选择对话框在后台弹出（Brave 正常） #37, shadows on callable services)
• 752dbee (会话归档后无法查看已归档的会话,并进行恢复. #40, canonical wrapped-fiber state) — the state handling is there; what is missing from Fiber.update is the return value, which is the 建议：为 Ralph 增加可选、有界的失败接续（failure successor） #109 item above
• 4cfd19a (def-site injection) — the same concept appears as origin where upstream says defSite. I did not establish whether the semantics differ, so I am not claiming it either way

Genuinely absent — the identifier does not occur anywhere in cordis/src:

• 8abd903 (爱你梁圣！ #35, track direct service callers): there is no symbols.caller at all, so ctx.logger cannot attribute a message to the fiber that logged it.

Final tally for this thread

	upstream	status
probe-verified missing	1b7d0f2, 2ceea23 (#109), 5b195b3 (#44), cb77029 (#53), 1c1a10e (#51), fd96b0a (#36)	6
absent outright	8abd903 (#35)	1
source-level, not reproduced	c594d1a (#121), c2835d8 (#123)	2
present, different shape	be7d36e (#37), 752dbee (#40)	2
unresolved	4cfd19a	1

Every one of the six carries a probe that runs against the shipped packages and against upstream cordis@4.0.0-rc.10 with nothing else changed. Happy to bundle them into a single script, or to open separate threads per area (loader / core / timer) if that is easier to route.

[173787247]

补丁：https://github.com/173787247/dsh-cordis-backport —— README、三个补丁、六条探针及其运行说明。仓库同时提供中文说明（补丁部分、探针部分）。

The patches are in that repository too — README, the three patches, and the six probes with run instructions. A Chinese translation of the README is available there.

Backports for the six are written and verified. Since this repository does not take pull requests, here is what they contain and what they do.

Three patches: cordis@4.0.4, cordis-plugin-loader@1.0.5, cordis-plugin-timer@1.1.6. Each touches src/*.ts and lib/index.js, because exports resolves to the bundle — changing src alone does not change what runs. The lib half is what let me verify without rebuilding; it is esbuild output, unminified.

upstream	file	before → after
2ceea23 (#109)	cordis/src/fiber.ts	update() returned undefined; a dropped call produced unhandledRejection: 'boom' → returns the task, rejects to an awaiter, nothing leaks
1b7d0f2	loader/src/config/{entry,group,isolate}.ts	new child had no fiber when await loader.update() resolved → reconciled
5b195b3 (#44)	cordis/src/events.ts	downstream ran 3 times silently → runs 2 and throws next() called multiple times
cb77029 (#53)	timer/src/index.ts	2 and 3 concurrent waiters both timed out → all settle in order
1c1a10e (#51)	cordis/src/events.ts	ctx.on('toString', …) threw hooks[method] is not a function → registers
fd96b0a (#36)	cordis/src/logger.ts	a held ctx.logger.buffer grew 2 → 3 → more → stays at 2

Each row is one probe run before and after. All three patches apply cleanly to untouched 4.0.4 sources.

One thing worth flagging

In 1b7d0f2 the group.ts hunk reads like a formatting change:

-    ctx.on('internal/update', (config) => {
-      this.update(config)
-    })
+    ctx.on('internal/update', config => this.update(config))

It is not. The first returns undefined; the second implicitly returns the promise, and the waterfall propagates a listener's return value out to Fiber.update's caller. That is where the await chain actually breaks. I skipped it as cosmetic at first, and the probe still failed with only entry.ts and isolate.ts changed — it passed once this went in.

Not included, deliberately

• 8abd903 (爱你梁圣！ #35, caller tracking) — symbols.caller does not exist here at all, so this is a feature rather than a repair.
• c594d1a (windows环境鬼打墙 #121) and c2835d8 (兄弟们这个好用吗？（观望） #123) — the include here deliberately vetoes the fiber restart and persists the config itself, with a comment explaining why. Whether to follow upstream there is a product decision, not a backport.

[173787247]

One more, on a different subject: a look at the part of this tree with no upstream counterpart — the volatile config machinery (cosmokit/src/volatile.ts, the schemastery support, and cordis-plugin-loader/src/config/diff.ts). Upstream has none of it, so unlike the backports above, none of it has been read by anyone outside the team that wrote it.

Result: it holds up. equalExceptVolatile decides whether a config change needs a remount, and the loader reads true as "no remount needed" — so a false true would silently swallow a real change. It passes 5000 seeded random config pairs (safety, reflexivity, symmetry) plus targeted cases for defaults, arrays, unknown keys and nesting.

Everything is in verify/ with the scripts and the setup, since Node refuses type stripping inside node_modules and the source has to be copied out first.

One missing guard did turn up, and the reachability argument is the interesting part:

function isSchemastery(schema: Plugin.Runtime['Config']): schema is Schema {
  return schema?.['~standard'].vendor === 'schemastery'
}

A non-nullish Config without ~standard gives undefined.vendor. It is not reachable — equalExceptVolatile is only called under fiber.state === ACTIVE, and a plugin with such a Config never activates, because resolveConfig in cordis/src/fiber.ts is missing the same guard:

if (!runtime.Config) return config
const result = runtime.Config['~standard'].validate(config)

Two missing guards mask each other. Fixing either one alone makes the other live. That is why this is written up rather than sent as a patch — a fix has to cover both, and it is a small robustness question rather than something anyone is hitting. Same class as upstream's open #141 / issue #102, incidentally: upstream's resolveConfig does throw on such a Config — I reproduced that — and this line happens to avoid it by resolving config after the state check instead of before.

For completeness, one behaviour recorded rather than asserted, because nothing relies on it and whether it should is a design call:

{}    vs absent (schema default present)  → false
null  vs absent (schema default present)  → true

?? treats null and undefined alike, so null falls through to the default. If a plugin ever wants null to mean "explicitly empty", that would need deciding.

[173787247]

Different subject again: I have been fuzzing the core state machine rather than diffing versions, and it found something upstream that reading never would have.

Upstream bug, PR #175: a fiber disposed before it ever activates keeps its disposables forever. _setEpoch(INACTIVE) returns at its first line when the epoch does not change — and for a PENDING fiber it does not — so _updateState() never runs and this._disposables is never cleared. That matters because a PENDING fiber can already own disposables: an observer of internal/plugin registers them while it waits, which is exactly how plugin-loader's Entry attaches. Everything an Entry registered on such a fiber — its internal/update and loader/partial-dispose listeners, its effects — is then never unloaded. The visible half is a stale state still reporting PENDING; the half that matters is the leak.

Two open PRs already touch this (#133, #140). Both add this._updateState(() => {}), which settles the state but still never unloads anything — I applied that line to upstream/main and measured the disposer count staying at 0. #175 unloads them and lets _unload()'s own _updateState settle the state as a consequence, so it covers both.

The part that is relevant to you: the vendored line in this repo already handles this correctly, and its comment is where the reasoning came from —

A PENDING fiber can already own effects registered by an internal/plugin observer. Its epoch is still INACTIVE, so _setEpoch() has no transition to drive; explicitly unload that pre-activation work before reporting disposal complete.

So this is a case of the vendored line being ahead, not behind. Nothing to do here.

Four seeded invariant fuzzers are in fuzz/ — lifecycles, nested fibers, multi-provider service selection, and concurrent operations with no settle in between. They pass on upstream with #175, and they fail on the first seed without it, which is how I know they detect something real rather than merely not crashing.

One caveat I want to state rather than bury. Run against @deepseek-ai/cordis@4.0.4, three of the four report violations that I could not reproduce in any minimal case. Disposing a PENDING fiber, disposing during the loading window, repeated load/unload cycles with a traced internal/status history — all show that line behaving correctly, with the transition sequence you would want. So I am not reporting those as bugs. Either the fuzzers reach something the minimal cases do not, or they are misreading that line's API somewhere (its anonymous fibers carry uid = 0 where upstream uses null, and that is the kind of difference that quietly changes an invariant). It is written up as unresolved in fuzz/README.md.

Two of my invariants were also wrong to begin with — effect counters incremented beside ctx.effect() rather than inside it, so a callback disposed mid-flight left a permanent phantom that looked like a leak. Both are recorded, because an assertion firing is not a finding.

[173787247]

A correction to my earlier summary, and a seventh item for the list. Earlier in this thread I closed out 752dbee (#40, keep wrapped fiber state canonical) as present, just implemented differently. That was wrong, and it is a real bug here.

What it does

registry.plugin() hands callers a wrapper, and the real fiber is its prototype:

const fiber = new Fiber(...)
const wrapped = Object.create(fiber) as Fiber & PromiseLike<Fiber>

update() and restart() then assigned through this — this.assertActive(), this._config = config, this.config = config, this._error = undefined, and every this.state = ... beneath them. Reached through the wrapper, those create own copies on the wrapper, shadowing the real fiber's fields. reflect.notify() iterates runtime.fibers, which holds the real fiber, so the two copies then diverge. Own property names after one update():

as shipped     [then, _config, config, _error, inertia, state, store]
upstream       [then]

Upstream dereferences at the top of both methods instead, which is the whole of that commit:

const fiber = this.ctx.fiber
fiber.assertActive()

What it costs

A ten-line reduction, deterministic:

const db = root.provide('b', 1)
const fiber = root.inject(['b'], async () => { await sleep(1); return () => {} })
await sleep(10)
fiber.update({ v: 1 })          // <- without this line both lines agree
await sleep(20)
db()                            // withdraw b

as shipped   after withdrawal   state=ACTIVE   _getState=PENDING   epoch=__INACTIVE__
upstream     after withdrawal   state=PENDING  _getState=PENDING   epoch=__INACTIVE__

The cached field disagrees with the epoch, nothing writes to state on that path at all, and the field is the one that gets read where it matters — cordis/src/reflect.ts:294 tests this.ctx.fiber.state === FiberState.ACTIVE before providing a service. So a fiber that has been reconfigured once can believe it is active after its dependency is gone.

It needs the update(). That is why the reduction took a while: removing any other single step still reproduces, because several subsets are each sufficient — the way to shrink it was to start from a passing baseline and add one step at a time.

Why the first pass missed it

The audit checked whether the identifiers a commit introduces are present. Every name 752dbee touches exists here, so it was marked as a different implementation. What the commit changes is the receiver of an assignment — no new name anywhere. A diff against upstream cannot see it; a fuzzer can.

That generalisation is the useful part for anyone reviewing this line: on a codebase with a wrapper/prototype indirection, "does this identifier exist" tells you nothing about whether a fix is present.

Status

Added to the backport set — cordis-4.0.4.patch is now ten hunks covering seven upstream fixes. With it applied the wrapper keeps only [then], and the reduction reports PENDING on both sides. Upstream's own tests for that commit assert exactly this, Object.hasOwn(fiber, 'state') === false, which is where I should have looked in the first place.

Updated: https://github.com/173787247/dsh-cordis-backport — the correction is written up in backport/README.md, the reduction is fuzz/06-stale-state-after-update.mjs, and the top-level READMEs now carry the corrected list.

[173787247]

The blind spot from the last correction was worth chasing. Re-checking the commits I had marked present with a behavioural test instead of a name check turned up two more — one a fix, one a confirmed divergence I am deliberately not patching.

Eighth fix: 10194de (#98) — a failed fiber must not re-enter the lifecycle

_setEpoch is missing its guard:

if (epoch === oldEpoch) return
// a failed fiber only recovers through update(), which clears _error
if (this._error) return          // <- absent here

So a fiber that failed to load gets its apply called again every time a dependency is withdrawn and re-provided, while its state stays FAILED:

as shipped   after a dependency refresh   apply called 2 times   state=FAILED
upstream     after a dependency refresh   apply called 1 time    state=FAILED

Anything apply did before throwing accumulates, and the fiber never becomes healthy enough for it to matter. Added to the patch set — cordis-4.0.4.patch is now twelve hunks covering eight fixes.

be7d36e (#37) — callable service shadows: confirmed, not patched

I ported upstream's own test for it verbatim. It fails here:

as shipped   Error: cannot get property "dependency" without inject
upstream     both calls return a Dependency instance

A callable service reached through [Service.extend]() loses its shadow, so the extension cannot reach the dependency its own inject declares.

This one is not in the patch set, and the reason matters. The visible cause is a single line — createShadow uses Reflect.getOwnPropertyDescriptor where upstream uses getPropertyDescriptor, and a class service's member lives on the prototype, so the lookup misses and the shadow is dropped. The helper getPropertyDescriptor is even already present in the file. But changing that line alone does not fix the test. The whole get trap in createTraceable is an earlier shape here; upstream reworked it in the same commit. That is a refactor of the shadow machinery rather than a backport, and I reverted my attempt instead of shipping an unverified half of it.

Test is at fuzz/07-callable-service-shadow.mjs if anyone wants to take it — it is upstream's test, so it is already in the shape a fix would need to satisfy.

What the re-check covered

upstream	verdict
10194de (#98)	missing — now patched
be7d36e (#37)	missing — confirmed by upstream's own test, not patched
8618a49 (#29)	present — has execute: function () and runner.execute.call(this)
8487fc5, 2df12b5, 542728e	present
4cfd19a	same machinery, still unresolved

So of the items I had cleared, two were wrong. Both for the same reason: I had been checking whether the identifiers a commit introduces exist here, and both of these change control flow or the receiver of an assignment instead. That check cannot see either. The list in the top-level README is corrected, and the patch set is at eight.

[173787247]

Last item on the list, and it closes the audit window. I had left 4cfd19a (resolve def-site service injection) as "same machinery, unresolved". It is missing, and the consequence is worth its own note.

Upstream's test for it, ported verbatim:

class FooBar extends Service { constructor(ctx) { super(ctx, 'foo.bar') } hello() { return 'bar' } }

class Baz extends Service {
  static inject = ['foo', 'foo.bar']
  probe() { return this.ctx.foo.bar.hello() }
}
class Qux extends Service {
  static inject = ['foo']            // injects foo, not foo.bar
  probe() { return this.ctx.foo.bar.hello() }
}

as shipped   baz.probe()                    -> "bar"
             qux.probe()                    -> "bar"          <- never declared foo.bar
             baz.probe() through ctx.inject -> throws
             qux.probe() through ctx.inject -> throws

upstream     all four behave as their inject declares

The first two lines are the part that matters. inject is how a plugin states what it depends on — the loader uses it to decide load order, the fiber uses it to decide when to activate, and reflect uses it to decide what a context may read. Here a service reaches a service it never declared, so the declaration stops being a reliable statement of what that plugin depends on. The other two lines are the mirror image: a service that did declare the dependency cannot reach it from a nested context.

Both of the remaining unpatched items — this and be7d36e (#37) — land in the same code: createShadow and the get trap of createTraceable in cordis/src/utils.ts, which this line has in an earlier shape. Upstream reworked that block across those two commits. I tried the obvious createShadow adjustment against each test separately; it fixes neither, so this is a rework of the shadow machinery rather than a backport, and I left it rather than ship half of one. Both tests are in fuzz/ in the shape a fix would need to satisfy.

The window is now fully adjudicated

All sixteen upstream fix commits between 2026-08-01 and the head of main:

backported — cordis-4.0.4.patch and the two plugin patches	9
confirmed missing, deliberately unpatched (the shadow gap)	2
deliberate divergence (include journal, project-relative specifiers)	2
a feature rather than a repair (symbols.caller)	1
not applicable — the hmr package is not shipped here	1
already present	1

Nine is the number in the patch set; the READMEs carry the corrected list, and the two unpatched items are written up with their upstream tests rather than as prose.

[173787247]

The last two items are done. I said earlier that be7d36e (#37) and 4cfd19a were confirmed but not patched, because both land in the shadow/traceable machinery and adjusting createShadow alone fixed neither. That was the right call for a one-line change and the wrong one for the actual port: the block is about fifty lines across two files, and upstream reworked it in those two commits, so it is one port covering both.

I also owe a correction on the framing. I wrote that porting it "is a refactor of the shadow machinery, and half of it is worse than none". The second half was right — shipping an unverified half would have been worse. The first half was me judging the size by reading the diff instead of counting it. It is 54 lines in createTraceable, 9 in createShadow, and 3 in reflect.ts, with createShadowMethod and applyTraceable identical in both lines.

What it fixes

as shipped   callable service via [Service.extend]()   Error: cannot get property
                                                       "dependency" without inject
             qux, which injects only `foo`             reaches ctx.foo.bar anyway
             baz, which injects `foo.bar`              cannot reach it nested

ported       all four behave as their `inject` declares

How it was validated

Not with my own probes only. The same 87 core tests from upstream, run twice — once with the vendored utils.ts and reflect.ts, once with the ported ones:

vendored (as shipped)   10 failed | 77 passed
ported                   5 failed | 82 passed

Five fixed, and no test that passed before fails after. That second half is the part I cared about, so I compared the failing test names rather than the counts:

✓ associated access follows the service fiber          (4cfd19a)
✓ uses the service shadow for callable extensions      (be7d36e)
✓ applies the service inject when entered from root
✓ resolves dependencies through a captured shadow
✓ strips service shadow before creating plugins

The five that still fail are all symbols.caller (#35). That stays out of scope on purpose: it is a feature rather than a repair, and the logger here reaches the def site by its own mechanism instead. Worth knowing if you ever want the upstream logger attribution semantics — that is the five, and it is the missing half of the same block.

cordis-4.0.4.patch is now 22 hunks covering eleven upstream fixes, and the whole set still applies cleanly to untouched 4.0.4 sources.

[173787247]

A twelfth fix, and this one is the most user-visible of the set. I found it by reading your own vendor/README.md, which was the right place to look and which I should have opened much earlier — more on that below.

eb5604d (#32): warn never reaches an exporter at the default level

LoggerLevel has two members the wrong way round:

// as shipped              // upstream
ERROR = 0                 ERROR = 0
INFO  = 1                 WARN  = 1
WARN  = 2                 INFO  = 2
DEBUG = 3                 DEBUG = 3

That matters because the exporter filter falls back to LoggerLevel.INFO as its threshold:

const targetLevel = exporter.levels?.[this.name] ?? exporter.levels?.default ?? this.level ?? LoggerLevel.INFO
if (targetLevel < level) continue

With INFO = 1, the default threshold is 1, and warn carries level 2 — so it is dropped before any exporter sees it:

as shipped   default level, exporter receives   [info]
upstream     default level, exporter receives   [info, warn]

ctx.logger.warn(...) does not appear in any log at the default configuration. error and info do. Nothing is thrown and nothing warns about it, which is the shape of problem that stays hidden for a long time. The patch is the two-line enum swap, plus the inlined default in the built lib (a const enum is inlined at build time, so ?? 1 also had to become ?? 2 — worth knowing if you apply this by hand).

A correction to how I scoped this

I had been auditing against a window I picked myself (August–September) and against my own reading of version numbers. Your vendor/README.md states the actual boundary: cordis is pinned to upstream 56b3d4f (2026-07-15), with 23 numbered local modifications layered on top, and it lists the manifest, the modification log and the sync procedure.

That is both narrower and correct. From 56b3d4f to the head of main there are 30 commits, 17 of them fix — and it explains something I had found confusing: the historical scan kept coming up "already present" because a good number of those local modifications are ports. Two of the log entries I checked (#11 patch id indexing, #14 durable debounced writes) are already fixed upstream, which is consistent with the log being written against an older snapshot.

All seventeen now carry a verdict: twelve backported here, two deliberate divergences, one a feature, one not applicable (the hmr package), one already present.

cordis-4.0.4.patch is 25 hunks covering the twelve, and the whole set still applies cleanly to untouched 4.0.4 sources.

[173787247]

Going back over vendor/README.md made me realise I had been producing the wrong artifact.

That file states the rule: "Keep this log exhaustive — every divergence from upstream must be listed." The twelve fixes have been sitting in a patch set and a probe suite, which is the code, but the thing your sync procedure actually consumes is the numbered log. So I have written the twelve as entries 23–34 in the log's own format:

https://github.com/173787247/dsh-cordis-backport/blob/main/for-dsh/vendor-log-entries.md

Each entry follows N. **file**: what changed. why. Covered by what., names the upstream commit it corresponds to so it can be retired at the next sync — the convention entry 7 already uses — and cites the probe that reproduces it. All twelve cited artifacts were checked to exist.

Three things worth flagging about the content:

Two entries need files the log does not otherwise track. Entry 31 (the LoggerLevel swap) also needs the built lib/index.js, because a const enum is inlined there as the literal _method() arguments and as the ?? 1 default in the export filter. Entry 32 (optional property widening) also needs the shipped lib/types/context.d.ts. Applying either to src alone does nothing.

Entry 30 is complementary to your entry 20, not an alternative. Your entry 20 fixes the wrapped-fiber defect at the loader's Entry; upstream's 752dbee fixes it at Fiber.update. I verified both directions — with entry 20 in place the loader is fine, but ctx.plugin() / ctx.inject() still hand back a wrapper that accumulates its own copy of the lifecycle fields for any other caller. Entry 30 is what closes that.

Entry 33 (the shadow rework) is the one to review most carefully. It is a ~65-line port across utils.ts and reflect.ts rather than a targeted fix, and it is the only entry here that changes behaviour beyond the defect it names. It was validated against upstream's own core suite — 10 failures to 5, with no test that passed before failing after — and the five that remain are all symbols.caller (#35), which is deliberately out of scope.

The patch set stays as the code half: cordis-4.0.4.patch (25 hunks), cordis-plugin-loader-1.0.5.patch (15), cordis-plugin-timer-1.1.6.patch (5), all applying cleanly to untouched 4.0.4 sources.

[173787247]

A closing note, because the most useful thing I found this round was not another defect — it was one of your own documents.

proposed/process/2026-06-11-supply-chain-and-vendor-drift.md

The vendor manifest is enforced at commit time in the forward direction (vendored change ⇒ manifest update) but nothing verifies the manifest's claims: that vendor/ actually equals upstream-at-SHA plus exactly the logged modifications.

That is the problem this thread has been circling, and you had already named it three months before I started. Your proposal #1 is the shape I ended up building by hand:

Vendor drift check (nightly CI): clone the upstream repos at the manifest SHAs (shallow), copy the corresponding package sources, and diff against vendor/*/src. The job fails unless the diff matches the logged local modifications — kept as a checked-in patch file per modification — the log entries become verifiable artifacts rather than prose.

backport/*.patch is the "checked-in patch file per modification" half; the probes and the invariant runner are the comparison half. I did not know that note existed until today, and I would have saved a lot of time if I had — the first half of this thread was me rediscovering the shape.

The one thing I can add to it

The proposal names its own blocker:

Upstream repos are private mirrors; CI credentials and availability are the main friction for the drift check.

For cordis and loader that blocker does not exist. Both come from cordiverse/cordis, which is public, and the manifest already pins the exact SHA (56b3d4f). A nightly job can clone it anonymously, check out the SHA, copy packages/core/src and packages/loader/src, and diff — no token. The other five packages come from deepseek-harness/cordis and keep the credential problem, but the two that matter most for upstream sync are the two that do not.

The matching worked example: this repository's differential runner takes one scenario, stages it into both lines, and reports agree / DIVERGE. It needs both lines checked out side by side, which is exactly what the drift job would produce.

What has accumulated since the last comment

• Four more findings, all reverse-direction — places where the vendored line is ahead of upstream: #176 (unloading effect registration), #177 (a throwing teardown observer aborts the rest), #178 (the constructor publishes the fiber before assigning its disposer), #179 (disabled: !!js is never evaluated). Fifteen upstream pull requests total; all four of these came out of reading vendor/README.md, which is now four for four as a source.
• An invariant suite derived from the paper, not from examples. cordiverse/paper → arXiv:2608.25512 defines revertible effects and reactive coeffects as the framework's two correctness properties. Fifteen of the findings in this thread land on one of those two. The suite runs against both lines and independently rediscovered 模型一直连接不上，报错 #175 from the property rather than from the fuzzer that first found it.
• The design-note corpus screened. .agents/notes/ is 2,412 files; 52 are bug-fix notes touching framework machinery, and exactly two describe a defect in vendored framework code. One is already mined; the other I chased to a verdict of not an upstream defect (EntryGroup.update under concurrent calls converges correctly on both lines). Write-up and full index in the repository.

One correction I owe the thread

Comment 12 said I had been producing the wrong artifact and switched to vendor-log entries. That was right, and it generalises further than I took it: the design notes are mostly "why we chose this", and the vendor log is "where we differ from upstream". Only the second one points at upstream defects. I spent a round treating 2,412 notes as a specification pool before measuring — it is a specification pool for understanding this tree, not for finding upstream bugs.

Artifacts, current: https://github.com/173787247/dsh-cordis-backport — 16 backport fixes as three patch files, 23 probes, the invariant runner, and the note index.

Not expecting a reply; there is nothing here that needs one. Posting it because the proposal note is actionable and the public-upstream point is the part that removes its stated blocker.