workers using *state.State

[Ian Booth]

Those workers below aren't the only ones. There's also minunits and peergrouper
workers.

No-one does these things on purpose. Just last week I caught and rejected a pull
request to introduce a new worker depending on state directly. People make
mistakes. Perhaps we should introduce a test which fails if state is imported
into any worker code. We have similar tests already for other forbidden imports.

On 08/09/15 17:12, William Reade wrote:
> People keep writing them, in defiance of sane layering and explicit
> instructions, for the most embarrassingly trivial tasks
> (statushistorypruner? dblogpruner? txnpruner? *all* of those can and should
> pass through a simple api facade, not just dance off to play with the
> direct-db-access fairies.)
> 
> There is no justification for *any* of those things to see a *state.State,
> and I'm going to start treating new workers that violate layering this way
> as deliberate sabotage attempts. Leads who have overseen the introduction
> of those workers, sort it out.
> 
> 
>