PR: https://github.com/Faction-V/platform-api/pull/357
Author: masha-maltseva (via Cursor)
Branch: feat/BE-762-feature-flag-registry-improvements → feature/BE-762-be-ff-enforce
Files changed: 1 (src/feature_flag_registry.py, +13 / -214)
- Adds
internal_only: bool = Falsefield toFeatureFlagDefinitiondataclass - Adds 2 new feature flag definitions:
composer-dashboardandchat - Sets
internal_only=Trueonsandbox-bannerandenv-toggle - Deletes 27 composer node-level feature flags (not mentioned in PR description)
The PR silently removes 27 feature flag definitions while the title and description only mention "adding" two new flags. The diff is net -201 lines. The deleted flags:
Category flags (5):
composer-agents,composer-data,composer-governance,composer-outputs,composer-tools
Individual node flags (9):
composer-agent,composer-deep-research,composer-structured-data,composer-unstructured-data-searchcomposer-guardrails,composer-evaluations,composer-human-intervention,composer-redaction
Output node flags (10):
composer-output-text,composer-output-json,composer-output-markdown,composer-output-powerpointcomposer-output-slides,composer-output-spreadsheet,composer-output-word-doccomposer-output-video,composer-output-text-to-speech,composer-output-data-visualization
Tool flags (4):
composer-tool-composio-search-finance,composer-tool-composio-search-groq-chatcomposer-tool-composio-search-exa-answer,composer-tool-composio-search-tavily-search
Questions to answer before merging:
- Does the frontend currently gate any UI elements behind these flags?
- Are there orgs in DynamoDB with these flags configured? Will removing them from the registry cause startup validation warnings (
main.pylogs unregistered keys)? - If these flags are genuinely unused, the PR description should explicitly state they are being decommissioned and why.
The internal_only: bool = False field is added to the FeatureFlagDefinition dataclass, but no code reads or acts on this field. The consuming locations were checked:
| File | Uses Registry? | Reads internal_only? |
|---|---|---|
main.py (startup validation) |
Yes — validate_feature_key() |
No |
cli.py (feature flag CLI) |
Yes — get_all_feature_flags() |
No |
dependencies/feature_flags.py (decorator) |
No — uses its own FEATURE_FLAG_REGISTRY |
No |
conftest.py (test fixtures) |
Yes — clears registries | No |
This means internal_only=True on sandbox-banner and env-toggle currently has zero effect. This is fine if consuming code is planned in a follow-up PR, but that should be noted in the description.
The description says:
- Added
composer-dashboardfeature flag definition- Added
chatfeature flag definition- Added
internal_only: bool = Falsefield
It does not mention:
- Removed 27 composer node-level feature flags (5 category, 9 node, 10 output, 4 tool)
For a +13/-214 line diff, the description should document the removals.
The existing registry tests (test_feature_flag_registry.py, test_feature_flag_registry_integration.py) don't reference the deleted flags by name, so they likely still pass. However, if any test validates the total count of registered flags, it will break. Worth verifying.
- Adding
composer-dashboardandchatflags that the frontend already uses is a valid gap to fill - The
internal_onlyconcept is sound — having global visibility control on the definition rather than per-org in DynamoDB is architecturally cleaner - Setting
internal_only=Trueonsandbox-bannerandenv-togglemakes sense as these are internal tooling flags
- Document the flag deletions in the PR description — explain why these 27 flags are being removed and confirm frontend impact has been assessed
- Verify no frontend breakage — confirm the frontend doesn't gate any composer node UI behind the deleted flags
- Either add consuming code for
internal_onlyin this PR, or note in the description that it's preparation for a follow-up - Run the registry tests to confirm they pass with the reduced flag set