test: expand v4→v5 upgrade test matrix with clustering config and hdb_status sub-cases#1207
test: expand v4→v5 upgrade test matrix with clustering config and hdb_status sub-cases#1207kriszyp wants to merge 3 commits into
Conversation
…us sub-cases Closes #1187. - Adds version matrix comment documenting HARPER_LEGACY_V43_PATH through V47_PATH env vars so CI can run the same suite against each v4 minor. - Adds hdb_status GTM table backward-compat suite: seeds a record via v4, upgrades to v5, verifies the record is readable (checks both data and system databases in case v5 migrated the table). - Adds v4.3.x clustering: config key suite: starts v4.3, seeds data, appends the old-style `clustering:` YAML block directly to the on-disk config file (bypassing HARPER_SET_CONFIG, which predates v4.3), then upgrades to v5 and asserts no crash and data survival. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request expands the upgrade compatibility test suite (v4.x to v5) by adding tests for the hdb_status GTM table backward compatibility and verifying that legacy clustering configuration keys do not cause silent startup failures in v5. The feedback suggests scoping the hdbStatusSeeded flag inside the suite callback to prevent state pollution, and writing the legacy clustering configuration to both potential configuration files (harperdb-config.yaml and harper-config.yaml) to ensure robust configuration resolution during the upgrade.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| let hdbStatusSeeded = false; | ||
|
|
||
| suite( | ||
| 'v4->v5: hdb_status GTM table backward-compat', | ||
| { skip: !legacyPath || testsBun || process.platform === 'win32' }, | ||
| (ctx: ContextWithHarper) => { | ||
| before(async () => { |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| const legacyConfigPath = join(ctx.harper.dataRootDir, 'harperdb-config.yaml'); | ||
| const newConfigPath = join(ctx.harper.dataRootDir, 'harper-config.yaml'); | ||
| const configPath = existsSync(legacyConfigPath) ? legacyConfigPath : newConfigPath; | ||
|
|
||
| // Append the old-style clustering block to the existing config file. | ||
| // YAML block append: a trailing newline then a top-level clustering key. | ||
| const clusteringYaml = [ | ||
| '', | ||
| '# v4.3 legacy clustering key — injected by upgrade compat test', | ||
| 'clustering:', | ||
| ' enabled: true', | ||
| ' nodeName: test-node', | ||
| ' server:', | ||
| ' port: 12345', | ||
| '', | ||
| ].join('\n'); | ||
| writeFileSync(configPath, clusteringYaml, { flag: 'a' }); |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
Reviewed; no blockers found. |
…d, write config to both filenames - Move `hdbStatusSeeded` flag from module scope into the suite callback to prevent state pollution between suites - Write the legacy clustering config block to both `harperdb-config.yaml` and `harper-config.yaml` so the test works across all v4.3.x minor versions regardless of which config filename convention they use Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Creates database/, resources/, and mqtt/ directories under integrationTests/ as placeholder structure ahead of merging #1207–#1211. Updates the top-level integrationTests/README.md with a directory map mirroring the Harper v5 docs and pointing new tests away from the legacy apiTests/ bucket (see #1215).
1 participant
Closes #1187.
Summary
HARPER_LEGACY_V43_PATHthroughHARPER_LEGACY_V47_PATHenv vars, with a note on how to run the CI matrix across v4 minors.v4→v5: hdb_status GTM table backward-compatsuite: seeds adata.hdb_statusrecord via v4, upgrades to v5, and verifies the record is readable — checking bothdataandsystemdatabases in case v5 migrates the table location.v4.3.x→v5: clustering: config keysuite: starts v4.3, seeds data, then appends the old-styleclustering: { enabled: true, ... }YAML block directly to the on-disk config file (bypassingHARPER_SET_CONFIG, which is a v5-only mechanism predating v4.3), then upgrades to v5 and asserts no crash + data survives.Areas for reviewer attention
data.hdb_statusthen falls back tosystem.hdb_status. The actual v4 schema location is not confirmed from source alone — if v4 stored it insystemfrom the start, thedataleg never seeds anything meaningful and the test is effectively a no-op. A reviewer with v4 knowledge should confirm.harperdb-config.yaml/harper-config.yamlexists after v4 starts. If v4.3 uses a different filename or writes no config file,writeFileSync(..., { flag: 'a' })will create a new file at thenewConfigPathpath — which may or may not be where v5 looks.hdbStatusSeededflag: This is safe for the current single-process test runner, but could cause issues if tests are ever run in parallel workers sharing module state (unlikely given the current setup).All three suites skip cleanly when the relevant env vars are absent (verified locally).
Generated by Claude Sonnet 4.6