Thanks to visit codestin.com
Credit goes to Github.com

Skip to content

Conversation

@MrEarle
Copy link

@MrEarle MrEarle commented Dec 5, 2025

This pull request aims to address #1407 and #1321.

Motivation

To prevent accidental disruptions in production environments, this PR adds a Read-Only mode.

Currently, access to the dashboard implies full control over the Celery cluster (stopping workers, rate limiting, etc.). This makes it risky to share the dashboard for simple monitoring purposes. This change adds a configuration option to hide administrative controls and reject state-changing API requests, ensuring the UI is safe for general viewing.

Proposed changes

  • Added --read_only cli option to enable read only mode.
  • Modified the API endpoints that use celery control features to return a 403 response if read only is enabled. Also, added tests to prove the change works.
  • Updated the worker UI template to hide these action buttons when read only mode is enabled.
  • Updated documentation with information about the new config option and response code.

Screenshots

(In all screenshots) Buttons to shut down the worker no longer show up.

Pool tab no longer shows actions for changing the pool size.
image

Queues tab no longer allows to cancel/add consumer
image

Limits tab no longer allows to apply values
[?] Should I just hide the entire tab?
image

How to test

  1. Start a Celery application: Ensure you have a celery worker running (e.g., celery -A my_app worker).
  2. Run Flower in Read-Only mode: Run the following command from the repository root:
    python -m flower -A my_app --read_only
    (Note: Adjust my_app to match your local celery application instance).
  3. Verify UI Changes:
    • Navigate to the dashboard (default: http://localhost:5555).
    • Click on a Worker to view the details.
    • Verify that the control buttons don't show in any of the workers tab
  4. Attempt to send a state-changing request via the API (e.g., shutting down a worker). You should get a 403 status code
    curl -X POST http://localhost:5555/api/worker/shutdown/worker1@hostname

@auvipy auvipy requested review from auvipy and Copilot and removed request for Copilot December 6, 2025 05:31
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR implements a read-only mode for Flower to prevent accidental disruptions in production environments. When enabled via the --read_only CLI option, it hides administrative controls in the UI and returns 403 responses for state-changing API requests.

Key Changes

  • Added --read_only configuration option with default value of False
  • Modified 11 API endpoints to check read-only mode and return 403 for control operations
  • Updated worker.html template to conditionally hide action buttons when read-only mode is enabled

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 27 comments.

Show a summary per file
File Description
flower/options.py Defines the new read_only boolean option
flower/api/control.py Adds read-only guards to worker control endpoints (shutdown, pool operations, queue management, task limits)
flower/api/tasks.py Adds read-only guards to task control endpoints (apply, async-apply, send-task, abort, revoke)
flower/views/workers.py Passes read_only flag to worker template for conditional rendering
flower/templates/worker.html Conditionally hides action buttons and controls based on read-only mode
tests/unit/api/test_control.py Adds test coverage for read-only mode on all control endpoints
tests/unit/api/test_tasks.py Adds test coverage for read-only mode on task apply endpoints
docs/config.rst Documents the new read_only configuration option

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@MrEarle
Copy link
Author

MrEarle commented Dec 11, 2025

@auvipy I addressed comments and fixed linters. Sorry about that, it wasn't clear how to run linters in the project.

It might be good to have a development document, to describe how to test the app, run tests, run linters and build docs. I had to figure them out by trial and error.

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