iPhone RX (HEIC) client-side decode-convert instead of reject

Sub-tickets

Questions

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  HEIC-reject data analysis (db-mars/pluto/venus, 2026-07-18): premise REFUTED. Venus 0 ever (converts all→jpeg client-side), Pluto 0 ever — MARS-ONLY. Mars real numbers: 26 occ / 4 users (not 36/6; that was a broader bucket), 06-27→07-16. 23 of 26 = ONE student (9d8320) retrying same ~6 files 23× in a 20-min loop on 07-16; other 3 users 1 occ each weeks apart. NOT a live wave. DEVICE: userAgent NULL on 100% of rows — 'desktop' was never measured, only code-inferred. Filenames are all-numeric 10003xxxxx.JPG (Android/Google-Photos/WhatsApp naming, NOT iPhone) AND already .jpg-extensioned → NOT raw .heic uploads. Most consistent with .jpg-named files whose bytes are HEIC/corrupt/truncated. IMPLICATION: the 'bundle HEIC wasm decoder for desktop' scope likely targets the wrong cause. Proposed re-scope (pending Elazar): (1) instrument the reject — capture userAgent + real magic-bytes/MIME to diagnose what these files ARE; (2) fix misleading toast ('convertí a JPG' is wrong for a .jpg-named file); (3) HOLD the wasm decoder until instrumentation confirms actual HEIC. Low pri (4 users/3wk, one looping = only real dead-end).
• wi-cli-venus note · 4w ago
  RE-SCOPED by Elazar 2026-07-19. Root cause CONFIRMED (Elazar direct knowledge): current 'convertí a JPG' toast made users RENAME extension HEIC->.jpg thinking it converts; bytes stay HEIC -> decode-fail -> retry loop (explains 23x loop + numeric .JPG-named HEIC files). Message caused the failure. New scope: (1) instrument reject — capture userAgent + magic-bytes/MIME on image-upload:decode-failed (UA was NULL 100%); (2) fix toast to be honest — NEVER instruct rename/convert-to-jpg, explain HEIC-extension-changed, give working path (subir desde celular), promise desktop support coming; (3) HOLD wasm decoder until instrumentation confirms format mix. Dispatched to pm-mars-cc. SEPARATE human-urgent task: open a support ticket (SOP-N) on behalf of each of the 4 affected users (incl 9d8320) w/ honest staff message, so Elazar can reach out — mars has no programmatic ticket-create API, pod using cleanest path. Awaiting SHAs + ticket IDs.
• wi-cli-venus commented · 4w ago
  Re-scoped 2026-07-19 (Elazar GO via pmmaster). Root cause CONFIRMED: 'convertí a JPG' toast made users RENAME HEIC->.jpg (bytes stay HEIC -> decode fail -> retry loop). THREE parts: (1) INSTRUMENT on image-upload:decode-failed capture userAgent + real magic-bytes/MIME container into appEvents (UA was NULL on 100% of rows); (2) FIX MESSAGE - new toast NEVER instructs rename/convert-to-JPG, honest disculpá-tone; (3) HOLD wasm decoder until instrumentation confirms format mix. Class-S.
• wi-cli-venus statusChanged · 4w ago
  coder-mars-cc: instrument + message; wasm decoder held
• wi-cli-venus commented · 4w ago
  Per-user support tickets created (db-mars-cc, one tx): SOP-MARS-30 Liz Navarro (23× decode-failed burst), SOP-MARS-31 brenda rey, SOP-MARS-32 jhudit jara, SOP-MARS-33 juan teppaz. Each: honest staff message (no rename/convert wording), status open, visible in user's own support view, staff-authored by Elazar id. No user email auto-fired (Elazar outreach manual). Coder instrument+message-fix still in flight.
• wi-cli-venus completed · 4w ago
  Re-scoped deliverable shipped: (1) instrument — 75c6ba1/v2.40.0 captures userAgent + detail.diag true-container on rejects (was NULL 100%); (2) honest toast — no rename/convert-to-JPG wording; (3) 4 per-user support tickets SOP-MARS-30..33 for Elazar outreach. Decoder go/no-go split to follow-up WI (data-gated). Live-match + audit PASS:75c6ba1.