Chill Bits

Files Dev — 13/02

—

Files Dev — 13/02

Theme of the day: Consistency is harder than correctness.

Today was less about building new features and more about tightening the system’s internal truth. The kind of work that doesn’t look dramatic from the outside — but determines whether the system behaves like a professional product or a collection of scripts.

1. Investigated Lumen log anomalies

I generated a structured operational report from the daily log (lumen-2026-02-13.log).

What stood out:

  • 30 ERROR entries.
  • All caused by the same Symfony highlight_file() failure.
  • No actual business logic errors visible (border, EXIF, Dropbox, etc.).
  • The real underlying exceptions were masked because the error renderer itself failed.

Lesson:

If your error handler is broken, your observability collapses. You don’t see what failed — you only see that the error page failed.

Operationally, this reinforced how critical infrastructure-level stability is. Fancy pipelines don’t matter if your exception layer can’t render safely.

2. Verified border-generation persistence logic

I audited whether POST /api/v1/border-generation correctly writes into border_generation_requests.

The key concerns:

  • Is request_key actually persisted?
  • Is idempotency enforced at DB level?
  • Are there scenarios where processing happens without persistence?

This step was about protecting idempotency — especially since bulk border generation must remain deterministic.

Lesson:

Idempotency is not a design claim. It must be enforced at the database boundary.

3. Audited EXIF extraction architecture

Today’s deeper thread was EXIF.

We confirmed:

  • The upload-triggered EXIF job.
  • The manual re-extract command.
  • The POST /api/v1/exif/get-bulk endpoint.

All must use the same canonical extraction logic.

Then I built an exif:audit command to compare:

  • Stored EXIF (DB)
  • Re-extracted EXIF (same logic as get-bulk)

The purpose: diagnose why some images were showing “sRGB” in certain places but “RGB” via the canonical extraction pipeline.

Result from audit:

  • Stored = RGB
  • Actual re-extraction = RGB
  • No mismatch.

But…

4. Found inconsistency in 

cloud_filename

Even though canonical EXIF says RGB, the cloud_filename still contained:

...-sRGB-11x14"-QTY---1---...Code language: CSS (css)

This revealed something subtle:

The EXIF logic was correct.

The database was correct.

But the filename generation layer was using older logic or stale data.

This is more dangerous than a crash — because it silently creates inconsistencies between metadata and naming conventions.

So I instructed that:

  • cloud_filename must derive colour space strictly from canonical EXIF logic (same as get-bulk).
  • No independent mapping layer.
  • No legacy override.
  • Canonical value must win.

Lesson:

In distributed pipelines, correctness must propagate.

One layer being correct is not enough — every dependent layer must consume the same source of truth.

5. Strengthened batch endpoint consistency

I also enforced that:

GET /api/v1/batch/{batch_uuid}

must return color_profile using the same canonical EXIF logic as get-bulk.

No parallel derivation.

No legacy interpretation.

Batch endpoint is read-only — but read-only endpoints can still lie if they use outdated transformation logic.

Lesson:

Read endpoints are just as important as write endpoints in maintaining system truth.

What I really learned today

  1. Observability failure can hide real system failures.
  2. Idempotency must be verified at persistence layer.
  3. “Single source of truth” is easy to say — hard to enforce.
  4. Inconsistent naming (like cloud_filename) reveals architectural drift.
  5. The real work at this stage of the system is not building new features — it is tightening invariants.

Today felt less like feature development and more like system hygiene.

And in a production pipeline that handles uploads, EXIF, borders, and publishing — hygiene is survival.