Org Web Adapter

Editing hungryroot/jira/be_7145_emit_checkout_submit_from_plan_order_after_db_commit_canonical_checkout_completed_metric.org

:PROPERTIES:
:ID:       03d8e79e-f280-421f-8e4c-6e9da28d0779
:END:
#+title: BE-7145 Emit checkout.submit from plan_order() after DB commit (canonical checkout-completed metric)

- source :: https://hungryroot.atlassian.net/browse/BE-7145
- tags   :: [[id:3a477c02-e26d-40f7-a719-0aa1cd169dd8][Hungryroot API Project]] 
- epic   :: [[id:86327fb4-0f66-4bc6-9068-c414cea77042][EP-411 Eng Parking Lot]]
- sprint :: [[id:30370b03-0b10-4105-87da-641cdda1bcb7][HR BE Sprint 104]]
- status :: [[id:ec92a960-cac1-4b05-b4f5-25a2935eea75][Status - To Do]]

* Description
Today DataDogMetrics.CHECKOUT_SUBMIT is emitted only in the legacy view
place_checkout_order after api.plan_order() succeeds. If anything raises after
plan_order() commits (Segment enqueue, CustomerInfo update, etc.), we can end up
with a real checkout in the DB but no Datadog metric. We should emit the metric
at the “checkout actually completed” boundary: when plan_order() transitions the
cart to a recurring order and activates the customer.

** Context

DB status transitions happen inside plan_order() (order.status = RECURRING,
customer.status = ACTIVE, stripe charge), in
[app/services/api/order.py](app/services/api/order.py) around plan_order lines
~570–660.

Metric currently emitted later in [app/views/api.py](app/views/api.py)
place_checkout_order() line ~1172.

** Acceptance criteria

checkout.submit is emitted exactly once per successfully planned first order.

Emission happens via transaction.on_commit (or equivalent) so it reflects
committed DB state.

Metric includes tags that let us break down by client (client_name) and/or
endpoint version.

Add test coverage for “metric still emitted even if post-checkout analytics
fail”.

Notes: Keep the existing emission temporarily if needed; add guard to avoid
double counting during rollout.