Five Empty States Behind One Blank Food Screen

Three fixes, one misleadingly empty interface

A blank food-data screen can mean that nobody entered the ingredients, a country has no matching products, the server omitted a facet, pagination is finished, or the request failed. Those states may look identical, but their safe next actions are almost opposites.

Three fresh Open Food Facts changes make the distinction concrete.

On August 29, Hunger Games merged a missing-field workflow. Its product panel previously used a question mark for null or undefined, while an empty array bypassed that fallback and rendered a completely blank cell. The change treats blank strings and empty arrays as missing too, then links contributors directly to the relevant edit field.

An Open Food Facts Explorer map fix, still open at publication, addresses a different kind of absence. Countries missing from a facet response had been assigned zero products. That invented zero affected the choropleth legend and defeated the map's no-data styling. The proposal now preserves explicit zeroes while leaving omitted countries without a count.

Meanwhile, Open Prices merged a 26-view frontend fix on August 28. When a paginated endpoint returned 404 {"detail":"Invalid page."} or a maximum-page error instead of an object with items, list views attempted to spread undefined, crashed, and left loading indicators active. The guard prevents that crash and preserves already loaded records.

The thesis: food APIs should represent emptiness as a typed outcome with scope, provenance, and recovery—not as a container shape—because a missing field, omitted aggregate, explicit zero, exhausted collection, and request failure require different product behavior.

Source map and the repeated angle to avoid

Fresh primary source	Status on August 29, 2026	What it contributes
Hunger Games actionable missing fields	Merged August 29	Shows null, blank strings, and empty arrays converging on one domain state, then becoming an edit action rather than a dead-end placeholder.
Open Food Facts Explorer missing-country map fix	Open; created August 27	Separates taxonomy membership, absent facet data, explicit zero, no-data styling, and empty-dataset legend behavior.
Open Prices frontend error-payload guards	Merged August 28	Shows how a protocol error shaped unlike a collection can crash many clients and leave stale loading state.

The ten most recent posts here cover search counts, ingredient parsing, exports, nutrition gates, evidence metrics, safety events, policy scopes, food-table migrations, and lot identity. Older articles already argue that unknown is not zero and that collection endpoints need pagination. Repeating either lesson would add little.

The new angle is recovery semantics across layers: who can resolve an empty state, what action is allowed, and whether the client should contribute, display no data, stop paging, retry, or escalate.

Five states that must not share one fallback

State	Example	Truthful client behavior	Dangerous fallback
Missing domain field	Product has no ingredient list	Offer an authorized contribution or mark incomplete	Render blank or infer “contains no ingredients”
Absent aggregate	Country is omitted from returned facets	Show no data and disclose aggregate coverage	Insert zero
Explicit zero	A returned facet says products: 0	Display zero	Treat as unknown and hide it
Exhausted collection	Valid traversal has no next page	Stop requesting and preserve loaded items	Request page after page until an error occurs
Request failure	Invalid cursor, page limit, timeout, or authorization error	Preserve prior data, end loading, expose retry or correction	Treat the error body as an empty successful collection

These are not merely UI labels. They affect recipe filtering, nutrition calculations, grocery price analytics, contributor queues, cache policy, and customer-facing claims.

For example, an empty ingredients array may mean ingestion has not happened, extraction failed, source evidence is unavailable, or a contributor explicitly declared an empty list. Only one of those is even plausibly a food fact. Likewise, a missing sodium value cannot become zero, while a laboratory or label value explicitly reported as zero must remain a usable observation with its rounding basis.

Use separate contracts for transport, coverage, and fields

One universal status field becomes vague quickly. Model emptiness at the layer where it occurred.

Transport outcome

A successful collection response should always have its documented collection shape—even when it contains no records:

{
  "items": [],
  "page": {
    "nextCursor": null,
    "hasMore": false
  },
  "total": {
    "value": 0,
    "relation": "exact"
  }
}

A failed request should use a stable error envelope and non-success status:

{
  "type": "https://api.example.com/problems/invalid-cursor",
  "title": "The continuation cursor is invalid",
  "status": 400,
  "code": "invalid_cursor",
  "retryable": false
}

The client adapter should branch on the HTTP outcome before deserializing the body as a collection. Checking if (!data.items) return is a useful crash barrier, but it cannot tell users whether paging ended, the request was invalid, or the service failed. A robust SDK returns a collection type only for successful collection responses and a typed error for failures.

Cursor traversal also avoids making “one page beyond the end” part of normal operation. The response that returns the final records should say hasMore: false. Clients still need in-flight request guards, idempotent page application, and stale-response protection; a continuation token does not prevent a user from triggering the same request twice.

Aggregate coverage

Facet omission needs its own contract because absence can be an optimization rather than a fact. A server may return only nonzero buckets, only the top 100 values, buckets above a privacy threshold, or buckets computed before a backfill finished.

{
  "facet": "countries",
  "buckets": [
    {"id": "country:fr", "count": 0, "countState": "explicit"}
  ],
  "coverage": {
    "mode": "requested_ids",
    "requestedIds": ["country:fr", "country:de"],
    "returnedIds": ["country:fr"],
    "omissionMeaning": "not_computed"
  }
}

Here France has an explicit zero; Germany does not have a count. If the endpoint instead guarantees a complete closed set, it may define omitted buckets as zero—but that guarantee must be part of the versioned endpoint contract, not a frontend assumption.

Field availability

Field state should say why a value is absent and what can happen next:

{
  "field": "ingredients",
  "value": null,
  "state": "missing",
  "reason": "not_contributed",
  "evidence": {
    "productRevision": 12,
    "sourceImagesAvailable": true
  },
  "actions": [
    {
      "type": "contribute",
      "method": "PATCH",
      "target": "/products/gtin:example/ingredients",
      "requires": ["authenticated", "source_evidence"]
    }
  ]
}

Useful states include present, missing, not_collected, pending, failed_extraction, not_applicable, redacted, and conflicting. Do not expose all of them as nullable booleans. redacted must not produce an edit link; pending may support polling; failed_extraction may offer review of source text; not_applicable should be terminal for that profile.

Make recovery part of the food-data product

The Hunger Games change is valuable not only because it detects empty arrays. It turns absence into a targeted workflow. A contributor looking at the product and its packaging can move directly to the missing field instead of seeing a question mark.

Recipe and nutrition systems can apply the same pattern:

• missing recipe yield → ask the recipe owner to confirm servings before calculating per-serving nutrition;
• unresolved package quantity → request a net-quantity image rather than inventing grocery units;
• failed ingredient normalization → open a review task with the source span and ranked candidates;
• stale price evidence → request a new store observation while preserving the last accepted price;
• unavailable nutrient reference → route to mapping review, not consumer data entry;
• authorization failure → ask for permission, not another contribution.

Actions must carry permissions and preconditions. A public client should not construct edit URLs from field names and hope anchors remain stable. The API can advertise allowed actions, while the server remains authoritative when an action is submitted. This also lets actions evolve independently from data fields.

Edge cases that expose weak contracts

Empty string versus intentionally blank. Whitespace-only ingredient text usually means missing input. An intentionally blank optional note may be valid. Define emptiness per field, not with one global helper.

Empty array versus completed negative assessment. allergens: [] is unsafe unless the contract says the assessment completed and found none under a named policy. Otherwise return assessment state separately.

Partial facets. Top-N facet responses must report truncation. An omitted ingredient category cannot become zero if lower-ranked buckets were excluded.

Previously loaded data plus an error. Infinite-scroll clients should preserve accepted pages, stop the spinner in a finally path, show the failed continuation separately, and avoid changing the reported total from an error payload.

Concurrent edits. A contribution link generated for product revision 12 may be stale after revision 13. Include revision preconditions and return a conflict that can reopen review safely.

Redaction and policy suppression. Missing values caused by privacy, licensing, tenant policy, or market restrictions require distinct states. “Add this field” would be both misleading and potentially harmful.

Release checklist for API producers and buyers

Before shipping or integrating a recipe, nutrition, grocery, or food-data endpoint, verify:

• successful collections always return one documented shape, including zero results;
• non-success responses cannot deserialize as successful collections;
• final-page state is explicit and does not require probing for an error;
• clients prevent duplicate in-flight continuation requests;
• explicit zero survives independently of null, omission, and not-computed states;
• facet responses declare completeness, truncation, and omission semantics;
• field emptiness rules are defined by field type;
• negative assessments are distinguishable from empty evidence;
• every actionable absence identifies the owner, target, permission, and precondition;
• pending, retryable, terminal, redacted, and conflicting states produce different actions;
• loading state clears on success, empty success, and every failure path;
• tests cover empty strings, empty arrays, absent keys, explicit zeroes, empty facets, final pages, invalid cursors, timeouts, and stale revisions.

A strong Recipe API does more than avoid null-pointer errors. It lets developers know whether the system has no recipe fact, no aggregate evidence, a real zero, no more records, or no successful response—and what can safely be done about each.

The durable rule is simple: do not make a blank container carry domain truth, protocol state, and workflow policy at once. Name the empty state at its source, preserve the evidence that distinguishes it, and attach only the recovery action that can actually improve the data.

Sources

• Open Food Facts Hunger Games, “feat(questions): make missing product fields actionable”, merged August 29, 2026.
• Open Food Facts Explorer, “fix: preserve missing country data in countries map”, opened August 27, 2026; open at publication.
• Open Prices frontend, “fix(Lists): don't crash when the API returns an error payload”, merged August 28, 2026.