ARR Job Trace Semantics for Internet Deployment

Question

Whether the ARR task trace is understandable when ARR is deployed on a server reachable through the internet, rather than being interpreted as if processing occurred on the operator's computer.

Findings

The current artifact_callback path is owned by ARR's fixed processor. It does not create a remote Agent/MCP run, so remote_run_id=null is expected and is not a failure.
Persisted delivery keys such as local-arrjob-...-a1 are delivery/idempotency identities. They are retained for compatibility and are not a claim about the user's machine or the server's geographic location.
A successful job with current_stage=downstream and DOWNSTREAM_EVENT_QUEUED has already committed the Finance version. publish_status=pending means the durable outbox event is waiting for its downstream consumer.

Change

The trace job summary now adds:

Field	`artifact_callback`	legacy `direct_mcp`
`execution_scope`	`arr_runtime`	`remote_agent`
`processor_mode`	`fixed_processor`	`legacy_direct_mcp`
`remote_dispatch`	`none`	`mcp`

User-visible messages now say ARR 固定处理器输出 and explicitly state Finance 数据库提交已完成 before the outbox wait. Existing delivery_mode, remote_run_id, trace version, persisted delivery IDs and privacy allowlist remain compatible.

Verification

python3 -m unittest tests.test_arr_web_job_trace tests.test_arr_web_task_log_ui tests.test_arr_web — 27 passed.
python3 -m py_compile arr_web/job_trace.py — passed.
node --check arr_web/static/app.js — passed.
git diff --check — passed.
No live task was rerun, no service was restarted and no Finance/report/Booking business data was changed.

Follow-up

After deployment, inspect one successful artifact_callback trace and confirm the additive header fields appear in the deployed CLI/API/UI. This is a display/observability acceptance step; it is separate from rerunning the historical 2026-07 company-report 11-20 publication.

2.0 KiB Raw Blame History