fix(settings): force the register import when the computed version differs — completes #391 - #400
Merged
Conversation
… stored OpenRegister's importFromApp(force: false) advances the stored configuration version whenever any registers/schemas/objects come back from the import, but does not apply property/authorization changes to schemas that already exist — only newly-created schemas get the full payload (ConductionNL/openregister#2075). A register edit that only touches an existing schema (e.g. catalog-ratings adding auteur/status/ authorization.read to the pre-existing beoordeeling schema) therefore advanced the stored version, made the instance look up to date, and left the schema stale — worse than a plain no-op, since the newly-written version also gated off every later non-forced import. Add SettingsService::resolveImportForce(): reads back the version OpenRegister already has stored for this app via ConfigurationService::getConfiguredAppVersion() (a like-for-like comparison against our own content-derived computeConfigVersion() signature) and forces importFromApp() whenever the two differ. Matching versions keep the existing cheap no-op path. An explicit caller-supplied force=true still always forces. Live-verified end-to-end via the non-forced GET /api/settings/load path (no force:true endpoint used): a throwaway probe property added to catalog-ratings.json landed on the live beoordeeling schema with force:false/effective_force:true logged, and removing the probe and re-running the same non-forced path removed it again and restored the exact original stored version string. Adds a ConfigurationService test stub and resolveImportForce() unit tests, and updates the REQ-003 spec with the new force-when-stale behavior.
This was referenced Jul 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Completes softwarecatalog#391. PR #396 fixed the version signature; live testing then proved that was necessary but not sufficient.
What live testing showed after #396
A normal
occ upgradeadvanced the stored configuration version (2.4.0+frag.9003c029→2.4.0+base.f6e72fc8+frag.92299b19) but did not apply the schema change — thecatalog-ratingsfragment'sauteur/status+ fail-closedauthorizationnever reachedbeoordeeling(schema 43). Root cause is upstream:importFromApp(force:false)advances the stored version without updating existing schemas — filed as ConductionNL/openregister#2075.That is worse than a plain no-op: the instance looks current while its schemas are stale, and the now-matching version gates off every later correct import.
Fix (consumer side, closes the gap for this app)
New
resolveImportForce()reads the version OpenRegister already stores for this app (ConfigurationService::getConfiguredAppVersion()— a like-for-like content-derived comparison against our owncomputeConfigVersion()) and forcesimportFromApp()whenever they differ. Matching versions keep the cheap no-op path; an explicit callerforce:truestill always forces. Commented with the openregister#2075 reference.Live verification (non-forced path only — the force endpoint was deliberately not used)
zzTestProbeproperty to the fragment →GET /api/settings/load(force=false) → log:"force":"false","effective_force":"true"→ probe present in the DB.2.4.0+base.f6e72fc8+frag.92299b19.appinfo/info.xmldiffs confirmed clean afterwards (independently re-verified).Tests: 465 / 1494 assertions, 0 failures. New
SettingsServiceResolveImportForceTestcovers versions-differ ⇒ force, versions-match ⇒ no force, explicit-force wins, plus null-stored-version and lookup-exception edges. Spec REQ-003 extended with 3 scenarios.Note: the previously pre-existing
PortfolioReportControllerTestCSV failure (#393) now passes on this HEAD.🤖 Generated with Claude Code