Darbplūsmas eksportēšana un atkārtota izpilde

Queuety var eksportēt pilnu darbplūsmas izpildes vēsturi pārnesamā formātā JSON un atkārtoti izpildīt to citā vidē. Tas noder ražošanas vides kļūdu atkārtošanai lokāli, darbplūsmu migrēšanai starp vidēm un auditēšanai.

Darbplūsmas eksportēšana

PHP API

Izsauciet Queuety::export_workflow(), norādot darbplūsmas ID. Tā atgriež ar JSON serializējamu masīvu:

use Queuety\Queuety;

$data = Queuety::export_workflow( $workflow_id );

Lai tieši iegūtu virkni JSON:

$json = json_encode( $data, JSON_PRETTY_PRINT );
file_put_contents( '/tmp/workflow-42.json', $json );

CLI

wp queuety workflow export <id> [--output=<file>]

# Print to stdout
wp queuety workflow export 42

# Write to a file
wp queuety workflow export 42 --output=/tmp/workflow-42.json

Darbplūsmas atkārtota izpilde

PHP API

Izsauciet Queuety::replay_workflow(), norādot eksportētos datus. Tiek atgriezts jaunās darbplūsmas ID:

use Queuety\Queuety;

$json = file_get_contents( '/tmp/workflow-42.json' );
$data = json_decode( $json, true );

$new_id = Queuety::replay_workflow( $data );

CLI

wp queuety workflow replay <file>

wp queuety workflow replay /tmp/workflow-42.json
# Success: Workflow replayed. New workflow ID: 85.

Struktūra JSON

Eksportā ir pilns darbplūsmas stāvoklis, saistītie uzdevumi, izsekošanas notikumi, žurnāla ieraksti, saglabātie signāli, artefakti, daļas un visas darbplūsmas atkarību gaidīšanas rindas:

{
    "workflow": {
        "id": 42,
        "name": "generate_report",
        "status": "failed",
        "state": { "user_id": 1, "_steps": [...], "_queue": "default" },
        "current_step": 2,
        "total_steps": 4,
        "parent_workflow_id": null,
        "parent_step_index": null,
        "started_at": "2026-03-28 10:00:00",
        "completed_at": null,
        "failed_at": "2026-03-28 10:05:00",
        "error_message": "API timeout",
        "deadline_at": null
    },
    "jobs": [
        {
            "id": 100,
            "queue": "default",
            "handler": "App\\Handlers\\FetchDataHandler",
            "payload": {},
            "status": "completed",
            "attempts": 1,
            "max_attempts": 3,
            "step_index": 0
        }
    ],
    "events": [
        {
            "id": 1,
            "job_id": 100,
            "step_index": 0,
            "step_name": "fetchData",
            "step_type": "single",
            "handler": "App\\Handlers\\FetchDataHandler",
            "event": "step_completed",
            "input": { "user_id": 1 },
            "output": { "records": 150 },
            "state_before": { "user_id": 1 },
            "state_after": { "user_id": 1, "records": 150 },
            "context": { "source": "api" },
            "error": null,
            "duration_ms": 230,
            "created_at": "2026-03-28 10:00:01"
        }
    ],
    "logs": [
        {
            "id": 1,
            "event": "workflow_started",
            "handler": "generate_report",
            "created_at": "2026-03-28 10:00:00"
        }
    ],
    "signals": [],
    "artifacts": [],
    "chunks": [],
    "wait_dependencies": [],
    "exported_at": "2026-03-28T12:00:00+00:00",
    "queuety_version": "0.22.0"
}

Daži lauki iepriekšējā piemērā ir saīsināti. Faktiskais eksports ietver visas izsekošanas kolonnas no katras notikumu rindas.

Darbplūsmu eksportos tiek saglabāti arī tādi darbplūsmas metadati kā definition_version, definition_hash un idempotency_key, ja tie bija iestatīti sākotnējā izpildē.

Kā darbojas atkārtota izpilde

Atkārtoti izpildot eksportētu darbplūsmu:

1. Tiek izveidota jauna darbplūsmas rinda ar eksportēto stāvokli un soļu definīcijām
2. Jaunās darbplūsmas nosaukums ir {original_name}_replay_{timestamp}
3. Jaunajā vidē no jauna tiek ievietoti vēsturiskie darbplūsmas notikumi un žurnāla ieraksti
4. Saglabātie signāli un darbplūsmu gaidīšanas atkarību rindas tiek atkārtoti atskaņotas kā vēsturiskais stāvoklis
5. Ja sākotnējā darbplūsma vēl bija running, apstrādei tiek iekļauts rindā pašreizējais solis. Repeat un start_workflows() soļi netiek iekļauti rindā atkārtoti, tāpēc atkārtota izpilde, kas apstājas pie viena no tiem, paliek statusā running bez uzdevuma (#17)
6. Ja sākotnējās darbplūsmas statuss bija waiting_for_signal, waiting_for_workflows, paused, failed, cancelled vai completed, šis statuss tiek saglabāts arī atkārtoti izpildītajā darbplūsmā

Atkārtoti izpildītā darbplūsma iegūst jaunu ID un darbojas neatkarīgi. Tā neietekmē sākotnējo darbplūsmu.

Atkārtoti izpildot waiting_for_workflows, eksportētās atkarību rindas tiek izveidotas no jauna ar tiem pašiem darbplūsmu ID. Tas noder auditēšanai un vidēm, kurās ir arī šīs atkarīgās darbplūsmas, taču atkarību ID starp vidēm netiek automātiski kartēti.

Lietojuma gadījumi

Atkārtojiet ražošanas vides kļūdas

Eksportējiet neveiksmīgu darbplūsmu no ražošanas vides un atkārtoti izpildiet to lokāli:

# On production
wp queuety workflow export 42 --output=/tmp/workflow-42.json

# Copy the file to your local environment

# On local
wp queuety workflow replay /tmp/workflow-42.json

Atkārtoti izpildītajai darbplūsmai ir tieši tāds pats stāvoklis un soļu definīcijas. Darbībā esošās darbplūsmas atkārtoti iekļauj pašreizējo soli rindā, lai varētu turpināt izpildi no vietas, kur tā tika pārtraukta, savukārt apturētās vai gaidošās darbplūsmas tiek atjaunotas bloķētajā stāvoklī, lai tās varētu pārbaudīt.

Migrējiet darbplūsmas starp vidēm

Pārvietojiet darbplūsmu no testa uz ražošanas vidi (vai otrādi), eksportējot un atkārtoti izpildot to:

# On staging
wp queuety workflow export 15 --output=workflow.json

# On production
wp queuety workflow replay workflow.json

Auditēšana un arhivēšana

Eksportējiet pabeigtās darbplūsmas ilgtermiņa glabāšanai vai atbilstības prasībām. Fails JSON satur pilnu izpildes vēsturi, tostarp ievades datus, izvades datus, stāvokli pirms un pēc izpildes, laika datus un informāciju par kļūdām.

$data = Queuety::export_workflow( $workflow_id );
// Store $data in your archive system, S3, etc.