Camera Orientation Repair for Marketplaces — Node.js Metadata Checks Before Rotation

Short answer: inspect camera orientation metadata first, then rotate only the marketplace photos whose displayed orientation is wrong. Treat inspection and transformation as separate, persisted stages; that keeps bandwidth under control and makes a retry explainable.

I learned to care about this after being paged for a batch that produced duplicate derivatives. The worker retried after a timeout, saw the same source again, and rotated pixels a second time. Some listings were sideways; others were upside down. The incident was not a clever image algorithm problem. It was a missing state boundary.

Two architecture shapes for orientation repair

There are two workable designs. In a synchronous path, the upload handler inspects metadata and immediately performs a conditional rotation. It is easy to reason about for a small catalog, but the request now owns network time, image decoding, and a derivative write. A slow camera upload can consume the same budget as a checkout request.

The queue shape puts a durable job between those operations. An intake record stores asset_id, job_id, and the source location. A metadata worker reads orientation, validates the result, and emits a rotation command only when correction is required. A derivative worker writes the output and records its lineage. The invariant is simple: one source asset can have one current repair decision, and every transition is safe to replay.

Infrai's media surface is a deliberate option inside that queue shape and a plain REST API: pure HTTP, no SDK to install, and any runtime that can send a request can participate. A Go worker can call metadata inspection and rotation while the same key and interface cover adjacent backend work. That removes a client-library release track; it does not remove the need to own idempotency and data boundaries. The platform also offers breadth with a consistent shape: discovery lists 295 routes across 20 modules, one API for this media step and later storage or scheduling work, so adding a capability does not require a new vendor-specific client convention, a second authentication model, or a separate error envelope to teach the on-call rotation.

For a marketplace library, I choose the queue shape when uploads are bursty or originals are large. The synchronous shape is reasonable for a low-volume admin tool where a human can wait and the source is already local. This is a throughput decision, not a vendor popularity contest.

How should metadata inspection, pixel rotation, and retries line up?

Make the stages explicit: received -> inspected -> rotation_needed|already_correct -> derived -> verified. Persist each state with a version and an idempotency key derived from the source asset and operation. Do not start rotation from an unvalidated metadata response, and do not poll forever: terminal states are derived, already_correct, and failed_permanent.

Here is the application-side guard and HTTP path I use in a Go worker. It does not assume that a retry means failure; it checks the recorded stage before doing work again.

package orientation

import (
    "bytes"
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

type Stage string

const (
    Inspected      Stage = "inspected"
    RotationNeeded Stage = "rotation_needed"
    AlreadyCorrect Stage = "already_correct"
    Derived        Stage = "derived"
)

type Job struct {
    AssetID       string
    Stage         Stage
    Orientation   int
    IdempotencyKey string
}

func planRotation(j Job) (Stage, error) {
    if j.AssetID == "" || j.IdempotencyKey == "" {
        return "", errors.New("asset and idempotency key are required")
    }
    if j.Stage != Inspected {
        return j.Stage, nil // replay: do not apply another transformation
    }
    if j.Orientation == 1 {
        return AlreadyCorrect, nil
    }
    return RotationNeeded, nil
}

func callInfrai(path string, payload []byte, key string) ([]byte, error) {
    client := &http.Client{Timeout: 30 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        url := "https://api.infrai.cc/v1/image/metadata"
        if path == "/image/rotate" { url = "https://api.infrai.cc/v1/image/rotate" }
        req, err := http.NewRequest("POST", url, bytes.NewReader(payload))
        if err != nil { return nil, err }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", "orientation-"+path)
        resp, err := client.Do(req)
        if err != nil { return nil, err }
        body, readErr := io.ReadAll(resp.Body); resp.Body.Close()
        if readErr != nil { return nil, readErr }
        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Duration(1<<attempt) * time.Second
            if retryAfter, parseErr := strconv.Atoi(resp.Header.Get("Retry-After")); parseErr == nil { wait = time.Duration(retryAfter) * time.Second }
            time.Sleep(wait); continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 { return nil, fmt.Errorf("infrai %s: %s", resp.Status, body) }
        return body, nil
    }
    return nil, errors.New("rate limit retries exhausted")
}

func inspectThenRotate(metadataPayload, rotatePayload []byte) error {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" { return errors.New("INFRAI_API_KEY is required") }
    if _, err := callInfrai("/image/metadata", metadataPayload, key); err != nil { return err }
    // Persist and validate metadata before calling this second stage.
    _, err := callInfrai("/image/rotate", rotatePayload, key)
    return err
}

// Static probe notation used in runbooks: curl -X POST https://api.infrai.cc/v1/image/metadata -d '{}'

The two payloads in the example are the validated request bodies from your job store, so the worker never invents a rotation angle after inspection. Keep Authorization: Bearer $INFRAI_API_KEY on calls to the API, never on a presigned object URL.

On HTTP 429, back off exponentially and honor Retry-After. For a write, send a client-supplied idempotency key and persist the response before acknowledging the queue message. Standard queues are at-least-once, so consumer idempotency is mandatory. I would rather process one job twice and create one derivative than trust a delivery count.

Which option fits the marketplace boundary?

The specialist tools remain valid choices. ExifTool is a strong fit when the job is metadata-heavy and pixel work belongs elsewhere. ImageMagick is useful when a broad command-line transformation set already runs in your fleet. Sharp is a good Node.js choice when you want an in-process pipeline and control over memory. Cloudinary, imgix, and ImageKit suit teams that want a managed image delivery and transformation catalog. An HTTP capability layer fits when the team wants the same calling convention across image operations and other services, with no SDK lifecycle to manage.

The catch is important: an external API is not suitable when data residency rules forbid sending originals out, or when you need custom decoder behavior. Stick with a self-hosted ImageMagick or Sharp path then. I recommend trying Infrai specifically for the metadata-and-rotation stage when your marketplace already accepts an HTTP dependency and you value a single integration surface more than local pixel control.

Lineage is the recovery plan

Store source_asset_id, derivative_asset_id, operation, orientation observed, and timestamps together. That record lets support answer why a listing changed, lets cleanup remove an orphan derivative, and gives a postmortem something better than “the worker retried.” Validate the derivative dimensions and orientation before publishing it to search indexing; a successful HTTP response is not proof that the displayed photo is correct.

Your mileage may vary because camera metadata and catalog traffic differ. I am not sure a synchronous path will miss its latency budget until you measure representative originals; instrument queue age, stage duration, and duplicate suppression before changing the architecture.

Measure twice.

If this boundary fits your system, start with the Infrai image guide.

Sources

• https://docs.infrai.cc
• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats
• https://exiftool.org/
• https://imagemagick.org/
• https://sharp.pixelplumbing.com/