# `LatticeStripe.Testing.Fixtures.MeterErrorReport`
[🔗](https://github.com/szTheory/lattice_stripe/blob/v2.2.2/lib/lattice_stripe/testing/fixtures/meter_error_report.ex#L1)

Canonical raw fixtures for Stripe billing meter error report events.

# `meter_error_report_event_json`

```elixir
@spec meter_error_report_event_json(map()) :: map()
```

The fully-fetched `v2.core.event` wrapping `meter_error_report_json/1`.

This is the shape `LatticeStripe.Webhook.fetch_event/3` returns — **not**
the delivered webhook body, which carries no `data` at all. `related_object`
names the meter, and it is the only place the meter id appears: `data` never
mentions which meter failed.

The top-level `reason` is `null` here, verbatim from the published example.
Do not confuse it with `data.reason` — see
`LatticeStripe.Billing.MeterErrorReport.SampleError` on the two
near-identically named idempotency keys this event carries.

# `meter_error_report_json`

```elixir
@spec meter_error_report_json(map()) :: map()
```

The `data` payload of a `v1.billing.meter.error_report_triggered` event.

Four fields, matching the published tree exactly: `developer_message_summary`,
`reason`, `validation_start` and `validation_end`. There is **no** `id`, no
`object` and no `livemode` — this is event data, not an addressable resource,
and a fixture that invented any of them would teach the wrong shape.

`validation_start` / `validation_end` are **RFC3339 strings**, not Unix
integers. That is the published encoding, verified against the live
reference, and it is a legitimate asymmetry against every v1 object in this
library (whose timestamps are Unix seconds).

The first sample error's `request.identifier` is the verbatim published
value — note it is a **bare UUID**, not one of this library's own
`idk_ltc_`-prefixed keys. Stripe echoes back whatever idempotency key the
failing write actually used, which is exactly why an adopter who lets
`LatticeStripe.Client` auto-generate one gets back a value that joins to
nothing they own.

The second error type carries `error_count` 900 with an **empty**
`sample_errors` list. That is the real high-volume shape — Stripe reports
the count without sampling every failure — and the decoder must yield `[]`
rather than `nil` for it.

# `meter_id`

```elixir
@spec meter_id() :: String.t()
```

The meter id carried by `meter_error_report_event_json/1`'s related object.

Exposed so a test can assert `from_event/1` lifted *this* value rather than
re-stating the literal and proving nothing.

# `no_meter_found_meter_error_report_event_json`

```elixir
@spec no_meter_found_meter_error_report_event_json(map()) :: map()
```

The sibling `v1.billing.meter.no_meter_found` event.

Its `data` tree is identical field-for-field to `meter_error_report_event_json/1`'s — the two events
share this payload byte-for-byte. The difference is that this one carries
**no `related_object` key at all**, so there is no meter id to lift and
`from_event/1` must leave `:meter` nil rather than raising.

---

*Consult [api-reference.md](api-reference.md) for complete listing*