Skip to main content

Reconcile Missouri Quilt Pixel IDs (ccp-3two.2)

Status: Awaiting human action — do NOT auto-heal.

Background​

Discovered during the 2026-06-02 prod onboarding audit (ccp-3two). Two onboarding records for Missouri Quilt (account_name MSQC and Missouri Quilt Co., AWS account 023568249301, prod-OnboardingTable) reference pixel IDs that have zero events in the S3 archive (pixel-ingestion-events-production). The actual live pixel (ID prefix 6fc2742c) emits events but is not referenced by either onboarding record — it is orphaned.

Because of this mismatch, the automated run_pixel_health_checks_batch checks always read zero events for these records and can never advance their completed_steps.

Why not auto-heal: fixing the records requires confirming which pixel UUID is actually correct for the Missouri Quilt storefront, then rewriting the pixel_id field on the record. Silent auto-repair risks binding the wrong pixel to the account.

Step 1 — Read the current onboarding records (read-only)​

Authenticate with prod AWS SSO (prod profile, account 023568249301):

aws sso login --profile prod

List all onboarding records and filter for Missouri Quilt:

aws dynamodb query \
  --profile prod \
  --region us-east-1 \
  --table-name prod-OnboardingTable \
  --index-name gsi1 \
  --key-condition-expression "gsi1pk = :pk" \
  --expression-attribute-values '{":pk": {"S": "ONBOARDING_LIST"}}' \
  --output json \
  | python3 -c "
import json, sys
items = json.load(sys.stdin)['Items']
msqc = [i for i in items if 'MSQC' in (i.get('account_name', {}).get('S','') or '') or 'Missouri' in (i.get('account_name', {}).get('S','') or '')]
for item in msqc:
    print(json.dumps({k: list(v.values())[0] for k, v in item.items() if k in ('onboarding_id','account_name','pixel_id','pixel_status','status','storefront_url','system_account_id','completed_steps')}, indent=2))
"

Record the following for each match:

FieldMSQC recordMissouri Quilt Co. record
onboarding_id
pixel_id (current — likely dead)
storefront_url
system_account_id
status
completed_steps

Step 2 — Verify the live pixel​

The audit found a pixel with ID prefix 6fc2742c emitting events. Confirm the full UUID and that it belongs to Missouri Quilt's storefront.

2a. Find the full pixel UUID​

Check the S3 event archive in the analytics account. The pixel-ingestion bucket is in a separate analytics account. Ask the analytics team or use the Analytics Internal Tooling Lambda (via the admin lambda's /api/v1/onboarding/{onboarding_id}/check-pixel-health endpoint against a temporary record, or directly invoke InternalToolingLambda-prod).

Alternatively, inspect the pixel script tag on the Missouri Quilt storefront:

curl -s https://www.missouriquiltco.com/ | grep -o 'pixel\.marqo-ep\.ai/c/[^/]*/[^"]*'

The URL pattern is pixel.marqo-ep.ai/c/{pixel_id}/. The pixel_id from this page is the authoritative live pixel. Confirm it starts with 6fc2742c.

2b. Confirm events exist for the live pixel​

Use the admin lambda locally against prod DDB:

AWS_PROFILE=prod BACKEND_ENV=prod pants run //components/admin_lambda:local

Then call the analytics tooling endpoint (replace <full-pixel-id> with the UUID from step 2a):

curl -s -X POST 'http://localhost:8000/api/v1/onboarding/<onboarding_id>/check-pixel-health'

Or invoke the InternalToolingLambda-prod directly with payload:

{
  "action": "sample_pixel_events",
  "pixel_id": "<full-pixel-id>",
  "count": 10
}

Expect events to be non-empty for the live pixel and empty for the dead pixel IDs.

Step 3 — Decide the repair action​

Choose one of the following options:

Option A — Keep one record, delete the other (recommended if one record is the canonical one)​

Identify which record is the correct/active one for Missouri Quilt. Typically this is the Missouri Quilt Co. record (registered status). The MSQC record may be a duplicate from a prior setup attempt.

  1. Update the surviving record's pixel_id to the live UUID (see Step 4).
  2. Delete the duplicate record (see Step 5).

Option B — Keep both records but update both pixel IDs​

If both records are in active use (e.g. different storefronts or contact groups), update both to reference the correct live pixel. Note: two records sharing the same pixel_id is allowed but the health checker will advance both records for the same pixel activity.

Step 4 — Update the pixel_id on the surviving record​

The admin API's PATCH /api/v1/onboarding/{onboarding_id} does not expose pixel_id as an updatable field. Update it directly in DynamoDB.

Read-back-before-write is important — the update in the data service does a full put_item, so fetch the current item first, modify just the pixel_id, and rewrite.

# 1. Read the current item
aws dynamodb get-item \
  --profile prod \
  --region us-east-1 \
  --table-name prod-OnboardingTable \
  --key '{"pk": {"S": "ONBOARDING#<onboarding_id>"}, "sk": {"S": "DETAILS"}}' \
  --output json > /tmp/msqc_item.json

cat /tmp/msqc_item.json  # Verify it looks correct before proceeding

# 2. Update just the pixel_id field
aws dynamodb update-item \
  --profile prod \
  --region us-east-1 \
  --table-name prod-OnboardingTable \
  --key '{"pk": {"S": "ONBOARDING#<onboarding_id>"}, "sk": {"S": "DETAILS"}}' \
  --update-expression "SET pixel_id = :new_pid, completed_steps = :steps" \
  --expression-attribute-values '{
    ":new_pid": {"S": "<full-live-pixel-uuid>"},
    ":steps": {"L": []}
  }' \
  --condition-expression "attribute_exists(pk)"

Clearing completed_steps to [] lets the health checker re-evaluate from scratch with the correct pixel ID on its next run.

4a. Verify the update took effect​

aws dynamodb get-item \
  --profile prod \
  --region us-east-1 \
  --table-name prod-OnboardingTable \
  --key '{"pk": {"S": "ONBOARDING#<onboarding_id>"}, "sk": {"S": "DETAILS"}}' \
  --output json | python3 -c "import json,sys; item=json.load(sys.stdin)['Item']; print(item.get('pixel_id',{}).get('S','MISSING'))"

Step 5 — Delete the duplicate record (Option A only)​

Only do this after confirming the surviving record now has the correct pixel_id.

aws dynamodb delete-item \
  --profile prod \
  --region us-east-1 \
  --table-name prod-OnboardingTable \
  --key '{"pk": {"S": "ONBOARDING#<duplicate-onboarding-id>"}, "sk": {"S": "DETAILS"}}' \
  --condition-expression "attribute_exists(pk)"

Step 6 — Trigger a health check run to verify recovery​

Call the batch health check endpoint to confirm the fixed record now advances its steps:

# Via the admin lambda locally (prod backend)
curl -s -X POST 'http://localhost:8000/api/v1/onboarding/run-pixel-health-checks' | python3 -m json.tool

Expect the Missouri Quilt record to appear in updated with new steps like pixel_receiving. If it still shows no events, re-check that the full pixel UUID in the record matches exactly what the storefront HTML serves.