Skip to main content

How to Debug "Fan Sees the Wrong Price" (or No Seats)

The most common production puzzle. A useful first instinct: when inventory looks wrong, it's very often the team's configuration in the ticketing system, not our code. This recipe orders the checks from most to least likely.

Use this when: a fan reports wrong prices, missing seats, missing suites, or a price that differs between two fans.

Before you start: steps 1–4 need read access to the team's database and the Cortex admin — if you don't have that yet (new joiners won't, until local setup is done), pair with someone who does and drive the checklist together.

1. Two fans see different prices? That's usually correct​

Pricing is per-rule, and two fans can legitimately qualify for different rules (account group, selected pack, event count). Before anything else, establish which pricing rule each fan resolved to:

  • Conditions live in tbl_pricing_rule_conditions (account group / package / pack / min event count).
  • Rules are checked by priority ASC NULLS LAST — first match wins, lower number = higher precedence.
  • Only status = 'published' rules load. A draft rule is invisible no matter how correct it is.

If the fan matched a rule you didn't expect, check for an overlapping rule with a better priority.

2. Check the rule's price rows for the event/suite​

The winning rule filters seats to its price combos. No combo row → no price → seat won't show.

The program's pricingModeLook in
event_leveltbl_pricing_rule_prices (ruleId, eventCode, priceCode, ticketTypeCode)
suite_leveltbl_pricing_rule_suite_prices (+ suiteId)
suite_tier_leveltier mapping + tier price tables

Typical miss: a new event (or new suite) was added but the rule's price rows were never extended to cover it. Cortex publish checks warn about this ("N suites missing pricing") — but only at publish time.

A second, very common self-setup miss: the rule prices on a price code (say A) that none of the built seats actually carry. Seats hold their price code in tbl_seat_price_mapping — if your inventory's seats are all code D/E but the rule prices code A, the price↔seat join is empty and nothing shows. Confirm a built seat actually has your price code, and choose a class name whose seats contain it (a class's available price codes show on its Cortex page). Real teams rarely hit this — they know their class/code layout — but it's the most common sandbox pitfall.

3. Suspect the team's vendor-side configuration​

Attend can only sell what the team assigned to our vendor user (e.g. Archtics user SEA854):

  • The class name must be assigned to our user — unassigned class = the vendor API simply doesn't return those seats.
  • Each seat needs its price code + ticket type code set at the event level on the vendor side.
  • Flex/Premium assume one class name across all events — a team that created a per-event class breaks that assumption.

4. Check inventory freshness​

The raw seat inventory is rebuilt about every 20 minutes (vendor seats sell elsewhere). For Premium / suite-level stores, fan reads then come from snapshots that rebuild more often (~5 minutes), so a config fix isn't visible until the next build that picks it up. For plain Flex seat-level stores there's no snapshot — reads go live through getInventory (authoritative), so the ~20-min raw rebuild is the freshness bound there. The build itself competes with the ~120 req/min per-DSN rate limit (a DSN is one client's Ticketmaster database connection — Chapter 17 explains it; all of Live Nation shares a single one), so a busy DSN can delay the rebuild.

5. Only then suspect our code​

If the rule, its price rows, the vendor assignment, and the snapshot all check out, then read the resolver (pricing-rule-resolver.service.ts) and the inventory queries with this fan's exact context. The purchase trace tutorial walks that path file by file.