Skip to content

refactor: save dynamic skills/classes immediately instead of a deferred queue - #1781

Open
Travja wants to merge 2 commits into
devfrom
split/1677-registration-manager-immediate-save
Open

refactor: save dynamic skills/classes immediately instead of a deferred queue#1781
Travja wants to merge 2 commits into
devfrom
split/1677-registration-manager-immediate-save

Conversation

@Travja

@Travja Travja commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Split out of #1677 (piece 8 of 8 — see that PR for the full breakdown).

What

RegistrationManager previously queued dynamic skill/class file saves and flushed them all in a single scheduled task after initialization completed. This removes that deferred queue (DeferredSave, queueDeferredSave/flushDeferredSaves, and the per-type queue* helpers) and instead saves each file immediately as it's loaded during initialization, following a soft-save → load → full-save sequence so optional fields get populated in the on-disk config right away rather than waiting for a later flush.

Why split out separately

Self-contained change to one class's save/load lifecycle; independent of the other pieces.

Note for reviewers

Worth extra scrutiny — this changes when/how often disk writes happen during startup. On servers with many dynamic skills/classes, this trades one batched save at the end of startup for several immediate synchronous saves during it, which could affect startup time or I/O patterns.

Testing

Could not build locally (private Maven repo unreachable in this sandbox). Needs manual/CI verification: dynamic skill/class configs still load and populate optional fields correctly, and startup time with a large number of dynamic skills/classes is acceptable.


Generated by Claude Code

…ed queue

Split out of #1677 (piece 8 of 8).

RegistrationManager previously queued dynamic skill/class file saves and
flushed them all in a single scheduled task after initialization
completed. This removes that deferred queue (DeferredSave,
queueDeferredSave/flushDeferredSaves and the per-type queue* helpers)
and instead saves each file immediately as it's loaded during
initialization, following a soft-save -> load -> full-save sequence so
optional fields get populated in the on-disk config right away rather
than waiting for a later flush.

## Why split out separately
Self-contained change to one class's save/load lifecycle; independent
of the other pieces. Worth calling out for extra scrutiny since it
changes when/how often disk writes happen during startup — on servers
with many dynamic skills/classes this trades a single batched save for
several immediate ones.
@Travja Travja mentioned this pull request Jul 21, 2026
Covers that a dynamic class's on-disk config file is rewritten during
registration itself (soft-save -> load -> save), rather than left as
the pristine input pending a scheduled flush this test never ticks
toward. Also covers that reloading multiple times in a row doesn't
corrupt the registered class - a scenario where the old deferred/batch
save queue could previously build up overlapping scheduled flushes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants