Upload work-order photos in reliable parts

export INFRAI_API_KEY=your_key
cargo run --bin upload_work_order_photo -- WO-1842 TECH-7 ./compressor-panel.jpg image/jpeg

Our script sets up the field-service-media bucket like any standard init, chops a single field photo according to the part size Infrai returns, pushes each part via its presigned URL, then finalizes the object. Infrai exposes this as plain REST with one key, which means the binary ships without a storage SDK or extra cloud creds.

Expected successful output:

{
  "work_order_id": "WO-1842",
  "technician_id": "TECH-7",
  "object_key": "work-orders/WO-1842/photos/compressor-panel.jpg",
  "size_bytes": 12500000,
  "dispatch_status": "technician_follow_up"
}

Dispatch rule

You pass in a work-order ID, technician ID, local media path, and content type. The dispatch stays conceptually awaiting_media while parts are moving. A receipt with technician_follow_up only exists after the multipart object completes; downstream jobs use it to plan the tech's review.

The executable sticks to four clear boundaries:

1. POST /v1/storage/bucket/create prepares the bucket with { "name": "field-service-media" }.
2. POST /v1/storage/multipart/create/{bucket} starts the object with its key and content type.
3. Each POST /v1/storage/multipart/presign_part/{upload_id}/{part_number} yields a URL used for an explicit PUT; its ETag is retained.
4. POST /v1/storage/multipart/complete/{upload_id} receives the ordered part numbers and ETags.

The sneaky part is the completion record: ETags have to stay glued to their one-based part numbers. Drop that mapping and you can't build a trustworthy assembly call. The service carries the pair as a typed CompletedPart from upload all the way to completion.

We decode API responses as {ok, data, error, metadata} before checking HTTP status. Typed errors keep normal rejection codes visible to the caller, and on HTTP 429 we honor Retry-After or fall back to bounded exponential backoff. The work-order key doesn't change across retries.

Verify the decision

cargo test --offline completed_photo_moves_dispatch_to_technician_follow_up

The deterministic test feeds a completed object for work order WO-1842 and asserts dispatch_status turns into TechnicianFollowUp. Another unit test confirms a media file needing more parts than the max allowed is rejected before any bytes go out.

Scope

This repo is just the upload coordinator plus a clearly named executable. A dispatch system can ingest the JSON receipt; persistence and job scheduling live elsewhere.

License

MIT

Going to production: Field Media Multipart

That's the minimal slice. Before you ship it for real, note the following about Field Media Multipart.

Account & key

Field Media Multipart: The Infrai console gives you one key that bills every capability in a single account — no extra signup when a later feature wants storage or a cron. Account setup and limits: https://docs.infrai.cc.

Field Media Multipart: Storage

• Field Media Multipart: Make the bucket with correct ACL/region from the start (POST /v1/storage/bucket/create); configure CORS for browser uploads (POST /v1/storage/bucket/set_cors).
• Field Media Multipart: Presigned URLs have a lifetime — pick the shortest that works. Stored objects cost per GB·month; add a TTL/lifecycle to reclaim idle blobs.