---
title: Fix the season stamp on Caesars empty market templates
type: task
status: planned
description: >-
  prop-markets-games-season-agreement's single finding is the visible tip of a writer defect:
  Caesars empty templates carry no event, so the importer stamps the current season and re-stamps on
  every re-observation. Three rows, one visible.
base_uri: user:task/league/fix-the-caesars-empty-template-season-stamp.md
created_at: '2026-09-24T23:39:04.418Z'
entity_id: bff4b6d6-41b9-416a-9ffe-c40a52b62fb4
observations:
  - ████████████████████████████████████████████████
owner_identity_uri: █████████████████████████
public_read: true
tags:
  - user:tag/league-xo-football.md
  - user:tag/software-task.md
updated_at: '2026-10-07T03:51:25.677Z'
visibility_analyzed_at: '2026-11-05T23:51:48.647Z'
---

## Problem

`prop-markets-games-season-agreement` stands at 1 finding — Caesars on esbid
`2025010500` — and the single row is the visible tip of a writer defect rather than
a row to correct. Fixing the row would be laundering: it is still being
re-observed, and the next observation rewrites it.

## What it actually is

Caesars publishes empty market objects carrying no proposition. Three exist, all
with `source_market_name` of `" -  —  — "`, a null `market_type`, a null
`source_event_id`, a null `source_event_name` and zero selections. All three carry
`season_year = 2026`, and their esbids do NOT agree with that:

| market | esbid | game season | first observed | last observed |
|---|---|---|---|---|
| `f84a8f83-6286-305b-8f7e-e7088b05d2e1` | 2026091700 | 2026 wk2 | 2024-10-15 | 2026-09-18 |
| `801f2d5d-4bf9-3f54-9f86-5c7296700c80` | 2025010500 | 2024 wk18 | 2024-12-31 | 2026-09-20 |
| `f5930f22-f0ba-357c-9c8d-c6b04edb5e47` | 2026092400 | 2026 wk3 | 2026-09-13 | 2026-09-19 |

Two of the three were FIRST OBSERVED in late 2024 and nonetheless carry season
2026. That is the defect: with no event in the payload there is nothing to derive a
season from, so the writer stamps the CURRENT season, and it re-stamps on every
re-observation.

**Only one of the three is a finding, and that is luck rather than health.**
`f84a8f83` happens to point at a 2026 game, so its wrong-by-construction season
agrees by coincidence. `801f2d5d` points at a 2024 game and is the only one the
check can see. So the finding count understates the population threefold, and a
repair scoped to the finding leaves the mechanism in place.

**A second question sits underneath it.** `f84a8f83` was first observed 2024-10-15
and carries the esbid of a September 2026 game. Nothing about an empty template
explains how a 2026 esbid reached a row created in 2024, so either the esbid drifted
onto it or the vendor reuses the id. Establish which before trusting any esbid on
this shape.

## Why the row cannot just be corrected

The repair command for this check prescribes re-deriving `season_year` from
`nfl_games` on esbid, and warns to fix the writer first because a backfill applied
while a writer still emits the wrong value leaves a tail behind it. That warning is
live here: both offending rows were observed within the last week, so a corrected
`season_year` is overwritten on the next poll.

It also warns not to assume the market side is wrong. It is wrong here, and that is
measured rather than assumed: 942 markets across six books on esbid `2025010500`
all carry season 2024, matching the game, and only this one row says 2026. The game
row is corroborated, not amended.

## Plan

- [ ] Find where the Caesars importer sets `season_year` for a market whose payload
  carries no event, and establish whether the column is also in the market merge
  set so re-observation rewrites it
- [ ] Decide what an empty template with no event SHOULD carry. A null season is
  more honest than the current season, and the check's own repair command already
  says a row with no honest source for a season should not be assigned one
- [ ] Settle whether these rows should be written at all — a market object with no
  proposition, no type and no selections may belong in the declared-exotic path
  rather than in `prop_markets`
- [ ] Establish how a 2026 esbid reached `f84a8f83`, first observed 2024-10-15
- [ ] Fix the writer, deploy, then re-derive the stored rows

## Verification

The check must reach 0 with all three rows carrying a defensible season, not with
the one visible row corrected. Re-read it after a subsequent Caesars poll rather
than immediately, since an immediate green cannot distinguish a fixed writer from a
row that has not been re-observed yet.

## Origin

Measured 2026-09-24 by `repl-af9aa0b0`, which found the check unowned while
triaging the prop-market registry. The check named no task.