Poda de estado

À medida que um fluxo de trabalho avança por muitas etapas, o estado acumulado pode crescer bastante. A poda de estado remove automaticamente as saídas de etapas antigas para manter o estado JSON limitado, preservando os dados importantes.

Ativando a poda de estado

Chame prune_state_after() no construtor do fluxo de trabalho. O argumento é o número de etapas recentes cujas saídas devem ser mantidas:

use Queuety\Queuety;

Queuety::workflow( 'long_pipeline' )
    ->then( StepA::class )
    ->then( StepB::class )
    ->then( StepC::class )
    ->then( StepD::class )
    ->then( StepE::class )
    ->prune_state_after( 2 )
    ->dispatch( [ 'input' => $data ] );

Com prune_state_after( 2 ), após a conclusão da etapa D, as saídas das etapas A e B são removidas do estado. As etapas C e D (as duas mais recentes) são preservadas.

Como funciona a poda

Quando a poda de estado está ativada, Queuety rastreia quais chaves cada etapa adiciona ao estado em um array reservado _step_outputs. Depois de avançar para uma nova etapa, as chaves introduzidas por etapas anteriores ao limite são removidas.

Por exemplo, com prune_state_after( 2 ):

After step 0 (StepA): state has keys from StepA + initial payload
After step 1 (StepB): state has keys from StepA + StepB + initial payload
After step 2 (StepC): state has keys from StepA + StepB + StepC + initial payload
  -> prune: StepA output removed (only 2 most recent kept)
After step 3 (StepD): state has keys from StepB + StepC + StepD + initial payload
  -> prune: StepB output removed

O que é preservado

Queuety nunca remove chaves reservadas que começam com _, como _steps, _queue, _priority, _max_attempts, _on_cancel, _prune_state_after e _step_outputs. As chaves do payload inicial passadas para dispatch() também são preservadas, pois não são rastreadas como saídas de etapas. Além disso, Queuety mantém as saídas das N etapas mais recentes, conforme o limite configurado.

Quando usar

A poda de estado é útil em fluxos de trabalho com muitas etapas, quando cada etapa produz dados de que as etapas posteriores não precisam. Exemplos típicos são pipelines longos em que cada etapa precisa apenas das saídas da etapa anterior ou das duas anteriores; fluxos ETL que geram estruturas intermediárias volumosas; e fluxos de trabalho recursivos ou repetitivos que, de outro modo, acumulariam estado redundante. Se o seu fluxo de trabalho tiver poucas etapas ou se etapas posteriores ainda dependerem de saídas iniciais, provavelmente você não precisa de poda.

Comportamento padrão

A poda de estado vem desativada por padrão. O método prune_state_after() aceita um argumento inteiro. Se chamado sem argumento, o valor padrão é 2:

->prune_state_after()     // keeps the 2 most recent step outputs
->prune_state_after( 5 )  // keeps the 5 most recent step outputs