Skip to main content

Context

The edge architecture temp specs assumed generic artifact upload and download endpoints for large task inputs, outputs, and log bundles. The current implementation uses a narrower task-data path:

  1. POST /internal/edges/tasks/next leases the next assigned task and returns the task payload as JSON.
  2. The edge agent executes the task locally and posts result rows to POST /internal/edges/tasks/:id/results.
  3. Completion uses POST /internal/edges/tasks/:id/complete with compact summary fields: best config IDs, processed count, and total count.
  4. Heartbeats carry progress counters and small status strings.

The current task payload is metadata-heavy: symbol, interval, search strategy, optimization parameters, metrics, trial settings, and optional price arrays. The current result payload is an array of strategy config and metrics objects, plus an optional resultFolder reference. No current code path uploads binary task inputs, log bundles, model files, or large output files for task execution.

Release artifacts are separate. Edge-agent upgrade packages already use HTTPS release URLs with checksum and signature verification, and that release flow does not require generic task artifact endpoints.

Decision

Do not add generic task artifact transfer for the next milestone.

Keep task payloads, heartbeats, result ingestion, and completion on the existing authenticated internal REST JSON endpoints. Treat object-storage task artifacts as a deferred capability until one of these conditions becomes true:

  1. Task inputs need large files or binary data that should not be embedded in JSON.
  2. Result outputs or logs need durable file retention beyond structured result rows.
  3. Payload or result sizes regularly exceed practical gateway/request limits.
  4. Operators need independent artifact retention, replay, or download permissions.

When those conditions appear, add follow-up issues for upload URL issuance, download URL issuance, authorization, retention, artifact reference schema, result reference ingestion, and operational visibility.

Consequences

  • Lower milestone scope: no object-storage dependency, signed URL API, retention policy, or artifact authorization model is needed for current task execution.
  • Clear boundary: release artifacts remain implemented as upgrade-package metadata; task artifacts remain deferred.
  • Smaller operational surface: task execution keeps one authenticated gateway path for payloads, progress, results, completion, and failure.
  • Known growth point: large task inputs, logs, or result files will require a new artifact design before they are introduced.

Deferred Temp Specs

The temp artifact transfer draft is not active architecture for the next milestone. It remains useful as a future design reference, but its upload/download URL endpoints and task artifact references are deferred by this decision.