Org Web Adapter

Editing journals/2026_06_04.org

:PROPERTIES:
:ID:       ea9877c7-108f-4b0d-bd8e-11c12e1454a8
:END:
#+title: 2026-06-04
#+filetags: :project:

* Meetings :work:meeting:sprint111:hungryroot:
** None
* Tasks :work:hungryroot:sprint111:
** DONE Update PR for BE-7818 :be7818:ep650:exp242:favorites:cookbooks:
:PROPERTIES:
:ID:       3747b9c7-3820-84a3-71e5-69ec81de3a62
:END:
** DONE Open a pull request adding share-able urls to Favorite Cookbooks :be7819:ep650:exp242:favorites:cookbooks:
:PROPERTIES:
:ID:       14485d1a-f10d-d76f-efcd-45e9be563626
:END:

*** Description

[[id:f2ed1b3c-bd0b-4d00-af31-87e42cb6234b][BE-7819 Exp 242 - Create sharable Favorites Cookbook shell on share]]

** DONE Investigate issue with Exp 242 data for Fanny :investigation:data:cookbooks:exp242:
:PROPERTIES:
:ID:       0efc8bcf-201b-42a0-8e4a-c2de9b2e4ae6
:END:
*** Description

[[id:7fcd79fa-1b2f-4d43-91f8-e94ea8527de8][BE-7859 Investigate and backfill missing Favorites experiment data]]

Fanny got me a bunch of CSV files that I need to figure out what to do with.

I *think* this is an issue of the data being in prod but not making it to a data
lake or something, but I need to do some research.

https://hungryroot.slack.com/archives/C0B7CUKNZ6F/p1780531230664279

*** Notes
- Note taken on [2026-06-04 Thu 17:02]
  
  That UUID format (3471c164-fb2d-...) is Segment's ajs_anonymous_id cookie —
  same one used in SearchExecutedEvent (hrsearch/views.py:104). The CSV came
  from a warehouse/Segment events table, not from MySQL.

This matters for the investigation: Fanny's data is from Segment event exports
  (where tag preference events were fired with the pre-auth anonymous identity),
  not from dim_customer_tags (which is derived from MySQL customer_tag). They're
  two different data sources.

Next question to answer: did those Segment events fire for these customers but
  the corresponding customer_tag MySQL rows are still missing, or does the row
  exist in MySQL and the CSV is just showing you the Segment-side record for
  context? Ask Fanny which warehouse table/query produced that CSV — that'll
  clarify whether the gap is app→MySQL or MySQL→warehouse.
  
- Note taken on [2026-06-04 Thu 11:40]
  
    Claude's take:

Source of truth: app/models/customer_tag.py → DB table customer_tag. This
  stores customer tag preferences — each row links a Customer to a Tag with a
  preference score and is_explicit flag.

The chain: Django app writes → customer_tag (MySQL) → ETL/dbt →
  shared_model.dim_customer_tags (warehouse)

The analyst is saying some customer's tag data is absent from the reporting
  table. Two possible causes:

1. App never wrote it — the CustomerTag row doesn't exist in customer_tag
       table.This would be a bug in our preference-setting flow
       (update_customer_tags in app/services/api/tag.py:167).
    2. ETL didn't sync it — the row exists in customer_tag but the pipeline that
       feeds dim_customer_tags missed it (replication lag, filter bug, failed
       job).

How to distinguish: check if the row exists in MySQL directly: SELECT * FROM customer_tag WHERE customer_id = <id>;

If row exists → ETL problem, not our code. If missing → app didn't write it,
  likely need to trace why update_customer_tags wasn't called for that customer.
    
** TODO Update Pairing.source_pairing help text BE-7488 :be7488:ep411:
** TODO Start work on a V2 endpoint for filter_pairings BE-6141 :be6141:v1tov2:v2migration:ep411: