[deenle]

Summary

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• CI/CD or infrastructure change

Related Issues

Changes Made

• Updated InfluxDB version across all affected configuration files.
• Updated README.md to reflect the new InfluxDB version.

Testing

• I have tested this locally
• I have added/updated tests that prove my fix/feature works
• All existing tests pass

Checklist

• My code follows the project's code style
• I have performed a self-review of my code
• I have commented my code where necessary (particularly complex areas)
• I have updated the documentation if needed
• My changes generate no new warnings
• No console.log, debug statements, or commented-out code

Screenshots (if applicable)

Additional Notes

[Starosdev]

Blocking finding

[P1] Add a supported rollback path for the persisted Omnibus database (docker/Dockerfile:34).

This changes the embedded InfluxDB version from 2.2.0 to 2.9.1 and migrates every existing Omnibus metadata volume in place. Reproduction with the official 2.2.0 and 2.9.1 binaries showed:

• The 2.2 -> 2.9 upgrade succeeds and existing authentication remains valid.
• Starting the current 2.2 image against the migrated volume exits with DB contains record of unknown migration and requires the 2.9 influxd downgrade command.
• After the required downgrade, 2.2 starts but authentication returns HTTP 401 because 2.9 hashes tokens by default and the downgrade removes those hashed records.
• Starting 2.9 with INFLUXD_USE_HASHED_TOKENS=false, then explicitly downgrading the metadata, preserves authentication under 2.2.

Before merging, provide a supported rollback procedure for existing Omnibus volumes. At minimum, stage token hashing appropriately and document or automate running influxd downgrade from the 2.9 image before rolling back to the current 2.2 image, including backup and token-recovery guidance. Disabling token hashing alone does not make a direct image rollback work.

Non-blocking: git diff --check also reports trailing whitespace in docs/INSTALL_MANUAL.md:13.

[deenle]

@Starosdev thanks for the fast review!
Sorry, I didn't test it thoroughly and expect that kind of issue.
Would you agree to add INFLUXD_USE_HASHED_TOKENS=false to the env's and always use it for now?

For downgrade, is it OK if we add a snippet to docs/TROUBLESHOOTING_INFLUXDB.md, like:

docker run --rm \
  -e INFLUXD_USE_HASHED_TOKENS=false \
  -v ./influxdb:/var/lib/influxdb2 \
  influxdb:2.9.1 \
  influxd downgrade 2.2

P.S. Trailing whitespace is pre-existing; I’ll clean it up.

[Starosdev]

Thanks. Yes, setting INFLUXD_USE_HASHED_TOKENS=false for the initial 2.9 rollout is acceptable. It must be active before the first 2.9 startup and remain enabled for now.

One correction: influxd downgrade 2.2 is invalid. InfluxDB 2.9.1 accepts 2.0|2.1|2.3|2.4; we verified that target 2.1 produces metadata that 2.2 can start successfully.

Please also require stopping Scrutiny and backing up the complete InfluxDB directory before downgrade:

docker compose stop scrutiny
cp -a ./influxdb ./influxdb.pre-2.9-backup

docker run --rm \
  -v ./influxdb:/var/lib/influxdb2 \
  influxdb:2.9.1 \
  influxd downgrade 2.1 \
    --bolt-path /var/lib/influxdb2/influxd.bolt \
    --sqlite-path /var/lib/influxdb2/influxd.sqlite

The environment variable is required during normal 2.9 operation; adding it to the downgrade command itself is unnecessary. Once these changes and the whitespace cleanup are pushed, I’ll re-review.

[Starosdev]

Thanks for the update. The core fix looks right: setting INFLUXD_USE_HASHED_TOKENS=false before the first 2.9 startup preserves the existing rollback path.

There is one functional scenario we still need to cover before approval. If someone already started 2.9 without that setting, their tokens have already been hashed. We reproduced the documented downgrade in that state: InfluxDB 2.2 started successfully afterward, but authentication returned HTTP 401. Please add a short warning and recovery path for those users, such as restoring the pre-upgrade backup or recreating the required token and updating Scrutiny’s configuration.

The current commands also match the Omnibus layout specifically. For Hub/Spoke, the service name and host data path differ. The simplest fix would be to label this procedure as Omnibus-only and add a brief Hub/Spoke variant.

Once those two cases are covered, the original rollback concern should be resolved.

[deenle]

@Starosdev hello!
I hope I got what you mean. Feel free to correct me if I’m wrong.

[Starosdev]

Thanks, yes, you’ve got the main issue and the updated downgrade flow looks good.

There’s one last practical detail from testing: when tokens were already hashed, the downgrade succeeds but the original token returns HTTP 401. Adding the recovery command below would make that path complete:

docker run --rm \
  -v ./influxdb2:/opt/scrutiny/influxdb \
  influxdb:2.2 \
  influxd recovery auth create-operator \
    --bolt-path /opt/scrutiny/influxdb/influxd.bolt \
    --org <your-org> \
    --username <your-username>

The generated token should then replace web.influxdb.token before restarting Scrutiny.

I’d also slightly adjust “if you manually enabled token hashing,” since stock InfluxDB 2.9 enables it automatically. Something like “if InfluxDB 2.9 was started without explicitly disabling token hashing” would cover the real case.

For Hub/Spoke, a short note telling users to substitute their configured container name and host data path is enough; no need to duplicate the whole procedure.

After that, I think the rollback concern is fully covered.

[Starosdev]

Thanks for taking the time to work through all the feedback. I verified the updated rollback and token-recovery procedure end to end against InfluxDB 2.2 and 2.9.1, including the already-hashed-token case. Everything worked as expected, so the original concern is resolved.

I’ve approved the PR, and CI is running now. Thanks again for the contribution!

[deenle]

@Starosdev thank you for the project!
I couldn’t have ironed out those issues on my own—your help and feedback made a big difference.