Skip to content

Conversation

@vicky-dx
Copy link

Description

Fixes #203 - Use distinct Redis database numbers to prevent conflicts when redis-main and redis-cache point to the same server

Problem

When redis-main and redis-cache are configured to point to the same Redis server (common in staging environments), there was a database number conflict:

  • REDIS_SESSION_URL was using database /2 on redis-cache
  • CELERY_BROKER_URL was using database /1 on redis-main
  • When both point to the same server, different services could accidentally share the same database number

Original Issue Timeline: Reported 3 years ago by @jnm

Solution

Changed REDIS_SESSION_URL from database /2 to /3 to ensure all database numbers are unique across both redis-main and redis-cache.

Changes

  • File: templates/kobo-env/envfiles/databases.txt.tpl
  • Line 50: Changed database number from /2 to /3
  • Change: REDIS_SESSION_URL now uses database /3 instead of /2

Redis Database Allocation

After this fix, the database numbers are:

redis-main:

  • /0 - Enketo (cannot be configured)
  • /1 - Celery broker (CELERY_BROKER_URL)

redis-cache:

  • /3 - Django sessions (REDIS_SESSION_URL) => CHANGED
  • /5 - Django cache (CACHE_URL)
  • /6 - Service account backend (SERVICE_ACCOUNT_BACKEND_URL)

All numbers are now distinct, preventing any conflicts when both Redis services point to the same server.

Testing

  • No breaking changes for separate Redis servers
  • Prevents database conflicts for shared Redis setups
  • Template syntax validated

Impact

  • Type: Bug fix / Enhancement
  • Breaking Changes: Session data will be stored in new database (users will be logged out once after upgrade)
  • Affected Users: Environments where redis-main and redis-cache point to same server (staging environments)
  • Risk: Low - only changes database number, no data structure changes
  • Performance: No impact

Migration Notes

When upgrading to this version:

  • Existing sessions will be lost (users need to log in again)
  • No data migration needed as sessions are temporary
  • All new sessions will use database /3

Related

- Improve stdout/stderr handling in CLI.run_command()
  * Separate stdout and stderr capture
  * Better error reporting and debugging
  * Fix subprocess.run() usage

- Remove code duplication in database user management
  * Create reusable __handle_db_user_changes() helper
  * Eliminate ~70 lines of duplicated code
  * Apply DRY principle

- Enhance directory validation
  * Add robust __is_valid_kobo_install_directory() method
  * Multi-file validation (git repo + key files)
  * More reliable installation detection

- Add customizable proxy port feature
  * Allow users to customize exposed_nginx_docker_port
  * Advanced mode option for external HTTP/HTTPS ports
  * Maintain backward compatibility

- Fix bugs
  * Resolve undefined backend_role variable
  * Fix type hint compilation errors

- Update .gitignore
  * Add Python best practices
  * Ignore venv, cache, IDE, and OS files

- Update tests
  * Fix test mocks for new CLI.run_command() signature
  * Support both docker-compose and docker compose formats
  * All 34 config tests passing

Fixes existing TODO comments and improves code maintainability.
- Changed REDIS_SESSION_URL from database /2 to /3
- Prevents conflict when redis-main and redis-cache point to same server
- Particularly helpful for staging environments
- Database number allocation:
  * /0: Enketo (redis-main, cannot be configured)
  * /1: Celery broker (redis-main)
  * /3: Django sessions (redis-cache) - CHANGED from /2
  * /5: Django cache (redis-cache)
  * /6: Service account backend (redis-cache)
- Resolves 3-year-old issue reported by @jnm
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.

Use distinct Redis database numbers (helpful when "main" and "cache" are the same server)

2 participants