task-trigger-service
Continuously running .NET 8 Windows Service that fires HTTP calls at other services on cron schedules — the estate's config-driven job scheduler for commission payments and Dynamics 365 integration.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | csharp |
| Frameworks | Generic Host (Windows Service), NCrontab.Advanced, NodaTime |
| Runtimes | .NET 8 |
| Tests / CI | good / CI in place |
| Last commit | 2025-11-27 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Platform services (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 1 release pipeline(s): \finance\task-trigger-service CI |
| Integration | rest |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loosely attached Bound into the core by 1 mechanism(s).
- Pinning dependency: application-framework
Detaches when its pinning dependencies are cut or multi-targeted (application-framework).
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
No excuseNothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Modern runtime, good tests, no hosted legacy transport: the automated stealth path can carry it today.
- Runs as a Windows service or scheduled task: deploy between runs or use overlapping instances; the load-balancer drain pattern does not apply directly
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Route deployments through the Workflow Engine's automated drain, deploy, health-check, return cycle (the path proven by the first automated production run in mid-2026).
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Ready to containeriseModern runtime, no hosted legacy transport: this service can follow the estate's proven container path (Dockerfile, shared pipeline template, ECS via Terraform).
- Convert the Windows service or scheduled task into a .NET worker service (or an ECS scheduled task) so it has a container-shaped lifecycle.
- Add a Dockerfile and make the app read all configuration from environment variables and the secrets manager, never from machine-local files.
- Log to stdout and expose a health check endpoint so ECS can supervise it.
- Adopt the shared ci.yml pipeline template with the container parameters (awsRegion, containerAfterBuild, ecsTerraformRepo), which is exactly how the estate's existing AWS services deploy.
- Define the service in the Terraform repo, deploy to a non-production environment, then shift traffic and disarm the deployment-group release pipeline.
Recommended actions
Rotate the credentials committed to task-trigger-service
Risk flags indicate credentials or keys in source (hardcoded-secrets). Rotate now and enable secret scanning in CI; this is independent of all other work.
Impact: Closes a live security exposure at near-zero cost
proposedAssessment notes
task-trigger-service
Purpose
A generic cron trigger host: cronJobs entries in appsettings define a cron expression, a ConnectionBroker target, an endpoint, HTTP method, payload and optional follow-on tasks (including fan-out over array responses). Production config drives two consumers — 19 jobs against CommissionPayment (monthly batch build/pay per company: UK, IE, NL, BE, AE, SA, AU, CA) and 18 against TOD365Integration — making it the heartbeat of the finance commission-payment cycle.
Tech stack
C# .NET 8 with the Generic Host and Microsoft.Extensions.Hosting.WindowsServices (Windows Service is the only supported host today, per the README). NCrontab.Advanced parses schedules, NodaTime handles timezones, and a worker/background-queue design (CronTriggerScheduleWorker, BackgroundTaskQueue, PollingService) executes triggers. New Relic agent enabled.
Deployment
Included as prod_application with 1 release via \finance\task-trigger-service CI from build pipeline task-trigger-service CI. YAML pipeline in the repo publishes the Windows host (win-x64) with per-environment appsettings (production, preproduction, testqa, datafixqa, liveproviderqa).
Dependencies
Internal packages: TC.ConnectionBroker.Api (tc-connectionbroker) resolves target base URLs, TC.Exceptions.* (tc-exceptions) reports failures, TC.Phenix.ApplicationFramework (application-framework). At runtime it invokes the commission-payment endpoints (backoffice-commissions-service) and the Dynamics 365 integration API (to-dyn365-api). External: New Relic monitoring.
Data stores
None — schedules live in configuration and all effects happen in the called services.
Integration points
Outbound REST only, with a common tc-api-key header (a GUID committed in appsettings.json) applied to all triggered calls.
Code health
Good: four test projects with 54 test source files covering core scheduling, options validation and checkers; thorough README documenting the cron job schema. Last commit 2025-11-27. Config-as-code means schedule changes require a redeploy.
Modernisation risks
Low: modern .NET 8 with solid tests. Residual concerns are the Windows Service-only hosting (blocks containerisation despite the code being platform-neutral), the shared API key committed in configuration, and single-point-of-failure status for commission payment scheduling — if this service is down, monthly batch runs silently don't start.