#906 activity_worker is forked: enterprise (1577 lines) and highway-core (1160) are parallel implementations of safety-critical worker code

open high engine resilience tech-debt Created 2026-08-22 11:58 · Updated 2026-08-22 11:58

Description

Edit
EARS SPEC: - Safety-critical activity-worker logic shall have exactly ONE implementation in the stack. - Where enterprise needs to extend core worker behaviour, it shall subclass or configure the core implementation, not maintain a parallel copy of it. FOUND DURING #860 (split of enterprise/services/activity_worker.py). THE DUPLICATION: enterprise/services/activity_worker*.py 1577 lines (8 files, post-#860 split) docker/highway-core/engine/services/activity_worker/ 1160 lines (8 modules, already a package) VERIFIED: `grep -rn "engine.services.activity_worker" enterprise api` returns NOTHING. The enterprise copy does not import, subclass, or delegate to core's. They are independent forks. STRONGEST EVIDENCE THEY ARE FORKS OF EACH OTHER: core's package already decomposes into circuit_breaker.py, claiming.py, config.py, execution.py, heartbeat.py, listen_thread.py, logging_helpers.py, worker.py and the #860 split of the enterprise copy independently arrived at essentially the same seams activity_worker_{claim,config,execution,heartbeat,listen,logging,core}.py An agent splitting the enterprise file by cohesion, with no knowledge of core's layout, reproduced core's module boundaries. That only happens if the two bodies of code are the same code. WHY THIS MATTERS MORE THAN ORDINARY DUPLICATION: This is the code that claims activity tasks, runs them under a bulkhead, heartbeats, and shuts down. A fix applied to one copy silently does not apply to the other. #850 upgraded bulkman and resilient-circuit for the whole stack precisely because a stale circuit-breaker signal is a real outage mode - but a behavioural fix in core's worker would not reach the enterprise worker, and the enterprise worker is the one the enterprise deployment runs. ALSO NOTE: the enterprise copy is what docker-compose runs as the `activity-worker` service. So core's implementation may be the DEAD one in this deployment - confirm which is actually executing before deciding the direction of consolidation. DECIDE: (a) enterprise subclasses core's ActivityWorker and overrides only what genuinely differs, or (b) core's copy is deleted if it is unused. Diff the two first and enumerate the real behavioural differences - do NOT assume they are identical just because they share structure.

Comments

Loading comments...

Context

Loading context...

Audit History

View All
Loading audit history...