Skip to content

feat(backend): run the task manager background services with the retention settings [INFP-507] - #10878

Closed
saltas888 wants to merge 13 commits into
activity-log-retention-infp-507from
background-services-infp-507
Closed

saltas888 wants to merge 13 commits into
activity-log-retention-infp-507from
background-services-infp-507

Conversation

@saltas888

@saltas888 saltas888 commented Oct 4, 2026 •

Copy link
Copy Markdown
Contributor

Superseded by #11289. The six INFP-507 PRs are consolidated there into one commit targeting develop, with the complete design, code-flow diagrams and contract-based review guide. This PR is closed to keep one active review; its branch and previous discussions are preserved.

Stacked PR 5/6 for INFP-507 (task history and activity log retention), in GitHub stack #10873 on develop. Review and merge bottom-up.

  1. feat(backend): add task manager retention settings [INFP-507] #10862: retention settings applied to Prefect
  2. feat(backend): clean up old task history in the task manager and during the upgrade [INFP-507] #10869: task history cleanup command, and the upgrade's task history hint
  3. fix(backend): keep the Activities page fast with a year of activity log [INFP-507] #10876: Activities page queries
  4. test(backend): guard the Prefect event-type list on the full stack [INFP-507] #10877: guard for Prefect's event types on the full stack
  5. This PR: infrahub tasks background-services
  6. docs: document task history and activity log retention [INFP-507] #10879: documentation

Why

Deployments that scale the task manager out run Prefect's background services (the cleanups, the event persister) in a separate container with prefect server services start. That command never loads Infrahub's configuration, so the task_manager.retention settings do not reach the services that enforce them: the flow-run cleanup stays off and events follow Prefect's defaults.

Closes part of INFP-507.

What changed

  • New command infrahub tasks background-services [CONFIG_FILE]. It loads Infrahub's configuration, applies the same derived Prefect settings as the task manager (same code path: a pre-set PREFECT_* variable wins with a warning, an invalid retention stops it), refreshes Prefect's settings, logs the values in effect, then calls Prefect's own start_services() in the same process, as prefect server services start does.
  • The test compose files (python_testcontainers/.../docker-compose.test.yml and docker-compose-cluster.test.yml) run the new command for task-manager-background-svc, and pass the three INFRAHUB_TASK_MANAGER_RETENTION_* variables through to that service and to task-manager.
  • apply_infrahub_settings_to_prefect takes an optional configuration file, so the command and the task manager share it.

Behaviour to note: the background services now log through Infrahub's logging at INFRAHUB_LOG_LEVEL (INFO by default) instead of Prefect's WARNING, which adds about two scheduler lines every 5 seconds in that container.

The Helm chart change (the background-services deployment runs this command, retention values in values.yaml) is opsmill/infrahub-helm#100, a draft until the chart's images move to Infrahub 1.13; the chart's upgrade hook needs no extra option.

How to test

uv run pytest backend/tests/unit/cli/test_tasks_background_services.py backend/tests/unit/prefect_server/test_app_retention.py

Checked on a scale-out test stack (INFRAHUB_TESTING_TASKMGR_SCALEOUT=1, image built from this branch, INFRAHUB_TASK_MANAGER_RETENTION_TASK_HISTORY=12d): the task-manager-background-svc container ran infrahub tasks background-services, logged Task manager retention: PREFECT_SERVER_SERVICES_DB_VACUUM_RETENTION_PERIOD=P12D, and scheduled vacuum_old_flow_runs, which Prefect does not run by default; test_prefect_event_types.py passed on that stack. /pre-ci passed.

Impact & rollout

  • Config/env changes: none new; the existing retention settings now reach separate background services.
  • Deployment notes: deployments that run prefect server services start themselves should switch to infrahub tasks background-services (changelog).

Checklist

  • Tests added/updated
  • Changelog entry added
  • External docs updated (PR 6 of this stack)
  • Internal .md docs updated (PR 6 of this stack)
  • I have reviewed AI generated content

🤖 Generated with Claude Code

@saltas888 saltas888 added type/feature New feature or request group/backend API server, GraphQL, task worker (Prefect), database, Python code labels Oct 4, 2026
@saltas888
saltas888 added this pull request to stack #10873 October 4, 2026 18:30
@github-actions github-actions Bot added the type/spec A specification for an upcoming change to the project label Oct 4, 2026
@codspeed

codspeed Bot commented Oct 4, 2026

Copy link
Copy Markdown

Merging this PR will not alter performance

✅ 13 untouched benchmarks


Comparing background-services-infp-507 (872ed77) with activity-log-retention-infp-507 (e14701a)

Open in CodSpeed

@saltas888
saltas888 force-pushed the background-services-infp-507 branch from 872ed77 to 35ded9c Compare October 4, 2026 20:04
@saltas888
saltas888 force-pushed the background-services-infp-507 branch from 35ded9c to 2905c9b Compare October 4, 2026 21:19
@saltas888
saltas888 force-pushed the background-services-infp-507 branch from 2905c9b to 4e158c2 Compare October 8, 2026 12:28
@saltas888
saltas888 force-pushed the background-services-infp-507 branch from 4e158c2 to 5a2a4b4 Compare October 8, 2026 12:55
@saltas888
saltas888 force-pushed the background-services-infp-507 branch from 5a2a4b4 to 744177d Compare October 8, 2026 13:42
@saltas888
saltas888 force-pushed the background-services-infp-507 branch 2 times, most recently from 825ed41 to cc05cd4 Compare October 11, 2026 20:04
@saltas888
saltas888 force-pushed the background-services-infp-507 branch 2 times, most recently from 0be0f2f to d1cfdc1 Compare October 13, 2026 15:35
saltas888 and others added 13 commits October 28, 2026 18:19
The command loads the Infrahub configuration from its CONFIG_FILE
argument, applies the task manager retention to Prefect's settings the
same way the task manager app factory does, then runs Prefect's
`prefect server services start` entry point in the foreground, in the
same process, so the services read the derived settings.

The task manager environment fixture moves to a shared helper so the
factory and command tests use the same isolation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…Infrahub

`task-manager-background-svc` now runs `infrahub tasks background-services`,
so the services apply the task manager retention like the task manager
does. Both the task manager and the background services pass the three
`INFRAHUB_TASK_MANAGER_RETENTION_*` variables through from the
environment; when they are unset, the Infrahub defaults apply.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…tch as done

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…er's own settings reader

The command now passes the configuration file as a path to the reader
that the task manager uses, which reads only the task_manager section.
Its tests use the shared isolation of the retention tests and expect
the empty per-type overrides that the default retention now logs.

The task manager's message for PREFECT__SERVER_WEBSERVER_ONLY now
names `infrahub tasks background-services` and is logged at INFO level,
because a correct setup with the services in their own process also
logs it. The changelog and the spec say the same.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…round-services command

Every infrahub command imported prefect.cli.server at startup, which loads
Prefect's command-line framework (cyclopts and about 40 modules), although
only `infrahub tasks background-services` uses it. The command now imports
it when it runs. The Prefect server API still loads for every command, so
the retention helper stays a module-level import.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…e services start with

The log lines that the command printed were already asserted by the task
manager's own startup tests, and three of the four settings by its
settings test. The command's test now checks only what the command adds:
the services start once, with the retention of the file it is given.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…guration file it is given

A mistyped CONFIG_FILE on the command line was read as an empty file, so
the services started with the default retention and deleted task runs
older than 30 days. A path given on the command line must now be an
existing file, or the command prints `Configuration file not found:
<path>` and exits with code 1 before it changes any Prefect setting. The
file that INFRAHUB_CONFIG names, or the default infrahub.toml, may still
be absent, as for the task manager, because deployments such as the test
compose files set every value in the environment.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…mmand through the CLI

The test ran the real command, so only the configuration validation kept
it from starting Prefect's services, which run until they are stopped and
write to Prefect's home directory. It now calls the function the command
delegates to with a recording starter and asserts that the services did
not start.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…-services command

The command runs under Infrahub's logging, which leaves the root logger at
INFO, and docket, which runs Prefect's services, logs two INFO lines for
every run of every service, about three lines a second.
`prefect server services start` printed none of them. The command now
sets the docket logger to WARNING after it applies the retention, so its
log keeps the retention lines and docket's warnings and errors.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…nit-test conftest

The command-line tests and the task manager startup tests each defined
the same fixture around the shared isolation helper. It now lives once in
the unit-test conftest.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
The group was hidden when it held only internal commands. It now holds
the background-services command that deployments run as a service and
the flush commands that the upgrade points to, so `infrahub --help`
lists it, and the group and its flush subgroup get descriptions. The
execute command gets a description of what it does.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…en for earlier images

The separate background-services container now runs
`infrahub tasks background-services`, which images released before this
command do not have, so the container exited and restarted in a loop.
INFRAHUB_TESTING_TASKMGR_BACKGROUND_SVC_COMMAND now replaces the command,
as PREFECT_SERVER_COMMAND already does for the task manager, so an earlier
image can run `prefect server services start`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
…k manager containers

The task manager and the separate background-services container write
Infrahub log lines, but unlike the API server and the task workers they
did not receive INFRAHUB_PRODUCTION or INFRAHUB_LOG_LEVEL, so they wrote
JSON at INFO whatever the test stack selected. Both now take the values
from INFRAHUB_TESTING_PRODUCTION and INFRAHUB_TESTING_LOG_LEVEL, and a unit
test checks every Infrahub container in both compose files.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwJNFw8rccyxc4Wp9eZFbH
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

group/backend API server, GraphQL, task worker (Prefect), database, Python code type/feature New feature or request type/spec A specification for an upcoming change to the project

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants