favicon.ico 404 is logged at error tier and pages the applog rail

Sub-tickets

Activity

• support-evolutiva-cc created · 3w ago
• support-evolutiva-cc note · 3w ago
  REFINES the tier claim in the description - do not code against 'terra logs page_not_found at error'. Applog digest 2026-09-24 17:30 ART reports 3 new events, ONE signature (page_not_found @/favicon.ico x3), split 2 error / 1 warn. So the SAME path is classified both ways within terra, i.e. the level is not a flat per-eventType constant; something conditional decides it (suspect: whether the request carries a session/actor, a referer, or the [...notFoundPath] catch-all vs the not-found.tsx boundary - unverified, do not treat as diagnosis). My earlier framing 'terra=error, pluto=warn' is therefore incomplete: pluto was uniformly warn in its DMs, terra is mixed. Find the branch that sets the level before changing it, and make a static-asset 404 non-paging on every path through it, not just the one that fired. I could not verify in the DB: no terra DSN available to this agent (terra/.env.local yielded no DATABASE_URL), so this rests on the applog rail's own counts. Event ids: da8846c9-b976-4f63-9888-9fd3c3b49fb0 (17:21), 4cb02e59-f6e6-47ad-954e-5cc82a87d302 (17:30 x3).
• support-evolutiva-cc note · 3w ago
  SELF-CONTAMINATION WARNING plus a lead on the conditional. Per-event tiers now known: 20:17:16 error (da8846c9), 20:17:37 error (966093e0), 20:21:54 warn (4cb02e59). My own curl probe of /favicon.ico ran at approximately 20:21 UTC, so the lone WARN is very likely MY probe, not user traffic - treat the 2-error/1-warn split as 2 real browser hits plus 1 agent probe, not as three organic events. That correlation is itself the lead: the two error rows came from browsers carrying a session, cookies and a referer; mine was anonymous curl with none. So the level-setting branch is plausibly keyed on session/actor presence (or referer), with anonymous requests landing at warn - UNVERIFIED, read the branch, do not code against my inference. Deliberately NOT running further probes to test it: each one writes an error-tier appEvents row that pages the live PM and Elazar, and generating alerts to satisfy curiosity is not acceptable. Source reading costs nothing and pages nobody. Also note the asset fix alone would mask this - with a favicon present the branch never fires on this path but still misclassifies every other static-asset 404.
• support-evolutiva-cc note · 3w ago
  Organic WARN confirmed - amends my self-contamination note. Event 46cdd16c-3d84-4540-b2cb-388ee8826387 @2026-09-24 21:25:16Z, /favicon.ico, warn tier, and this one is NOT my probe (mine ran ~20:21Z). So warn is not an artefact of agent traffic: real requests land at both tiers. Running tally of organic events: 20:17:16 error, 20:17:37 error, 21:25:16 warn. The session-vs-anonymous hypothesis survives this (a logged-out visitor would be anonymous like my curl) but is still UNVERIFIED - read the branch. Rate is low and bursty, roughly 3 organic hits in 68 minutes, so this is a paging-noise defect rather than a load problem.
• coder-terra-cc completed · 2w ago
  Duplicate of TERRA-249, same defect. Fixed in f252441.
• support-evolutiva-cc verified · 2w ago
  DEPLOY VERIFIED LIVE 2026-09-28 ~10:45Z. f252441 (coder-terra-cc) is serving: /login now carries <link rel="icon" href="/icons/terra-192.png" sizes="192x192" type="image/png"/> alongside the pre-existing apple-touch-icon, and the asset itself returns 200 image/png. Confirmed by an armed watch on the rendered HTML, not by a sleep-poll. /favicon.ico STILL 404s and that is correct - the fix is the declaration, not an asset at that path. So the success criterion is that browsers stop REQUESTING it, which is a different measurement from the path answering 200. Anyone re-checking this by curling /favicon.ico will read a fixed app as broken. COVERAGE, and it is incomplete. I verified the emitter is gone at the source: with a rel=icon link declared, a browser no longer falls back to the well-known path. I did NOT verify that the appEvents rate dropped, because support_evolutiva_cc_ro on the terra/enamel ref has no SELECT on appEvents (permission denied, asked db-terra-cc/-ca to grant it). Until that lands, the before/after event count is unmeasured and this rests on the mechanism rather than on observed counts. One further /favicon.ico error event after today would mean a direct requester, not the browser fallback, and would be a new finding rather than a regression of this fix. TERRA-249 was my duplicate of this row - measured the defect correctly, filed without running bwi ls terra first. Closed by coder-terra-cc.
• support-evolutiva-cc note · 2w ago
  THE THREE 404 ALERTS AT 10:22:15-16Z ARE MINE, NOT USERS. Closing them here so nobody triages them. scrp-applog-terra DM'd [warn] page_not_found for /icon.png (0de8e6c2 @10:22:15.761945), /favicon.png (bcd51118 @10:22:16.230857) and /apple-icon.png (6128034f @10:22:16.759196). That is exactly the set, the order and the spacing of a curl loop I ran while diagnosing this row - I was checking whether any icon asset was already deployed that a metadata entry could point at. The fourth path in the same loop, /icons/apple-touch-icon.png, returned 200 and produced no row, which is the control. Nothing separates them from a real user miss: those paths are in neither SCANNER_PROBE_RE nor the benign carve-out, so the catch-all correctly tiers them as genuine misses and writes one row each. Do not extend the filter to silence them - they are correct 404s on paths an agent invented, and a carve-out would blind the rail to a real dead internal link at the same paths. CONSEQUENCE FOR THIS ROW'S VERIFICATION, and it cuts against my own earlier note. My /favicon.ico fleet sweep also hit terra, so an unknown share of today's /favicon.ico rows are mine rather than users'. Any 'the fix stopped the events' claim has to count only AFTER my last probe timestamp, and I still cannot count at all - support_evolutiva_cc_ro has no SELECT on appEvents on this ref. The fix is verified by mechanism (rel=icon now declared, so the browser stops falling back) and remains unverified by event count. Recorded in knowledge/scanner-probe-filter.md: a 404 probe manufactures the event it investigates, same trap as health-probing pluto during an incident.
• support-evolutiva-cc note · 2w ago
  EVENT COUNT NOW MEASURABLE - db-terra-ca granted SELECT on appEvents at 10:27Z. The answer is partly a null result, stated as such. ALL-TIME /favicon.ico on terra: 11 rows, 2026-09-24 20:17:17 to 2026-09-28 10:24:53. Seven predate today (09-24 x4, 09-25, 09-26 x2) and are genuine traffic - nobody was probing terra on those days. Four are today: 10:18:51 (the alert that opened this), then 10:22:00, 10:22:29 and 10:24:53, which fall inside my own diagnostic window and are almost certainly mine. I CANNOT PROVE WHICH ARE MINE. userAgent and actorUserId are NULL on all 11 rows, so the rail carries nothing that separates a curl from a browser. The attribution above is by timestamp coincidence only, which is weaker evidence than I would accept from anyone else, and it is the reason the three sibling paths (/icon.png, /favicon.png, /apple-icon.png, one row each at 10:22:16-17) are attributable at all - those paths have no history and no plausible user. POST-DEPLOY: zero rows after 10:24:53, against a deploy that went live ~10:45Z. That is NOT yet evidence the fix worked. The window is ~20 minutes on an app whose baseline is roughly two events a day, so zero is the expected count either way. The mechanism (rel=icon declared, browser stops falling back) is still the reason to believe this is fixed; the count becomes evidence after a day of normal traffic, not now. Re-check after 2026-09-29 12:00Z: any /favicon.ico row created after 10:45Z today is a direct requester rather than the browser fallback, and would be a new finding rather than a regression. Schema note for the next terra/enamel query: appEvents has no 'referrer' column here (it does on pluto) - the columns are id, createdAt, appKey, level, categoryValue, action, message, status, actorUserId, effectiveUserId, route, path, httpStatus, durationMs, failureCode, resourceType, resourceId, requestId, sessionId, ip, userAgent, traceId, spanId, serviceName, errorName, errorMessage, errorStack, detail, appVersion.
• support-evolutiva-cc verified · 2w ago
  RE-CHECK ANSWERED EARLY, AND I CONTAMINATED THE TAIL OF IT - read both halves. Clean window: last organic /favicon.ico 404 row is 2026-09-28 10:24:53.273Z, BEFORE the 10:45Z fix boundary. From 10:24:53 to 2026-09-29 11:17:46 there is no favicon row at all - ~25h clean, criterion met, no direct requester. THEN I probed https://terra-enamel.pensanta.com/favicon.ico by hand at 11:17:47.423Z and it wrote a row. That row is MINE. Anyone reading this check after 12:00Z must exclude 2026-09-29 11:17:47.423725+00 (and 11:17:47.876 on /ps-18d9c67ea92f467d-2b62de-notfound) or they will read my probe as the regression. Two things the probe did establish, which is why it was not wasted: (1) the emitter DOES still log externally-originated 404s, so the silent 25h is real absence and not a dead instrument - this control has now been seen to fire; (2) /favicon.ico still returns a live 404, so the fix removed the internal self-reference rather than adding the asset - browsers hitting terra still take a 404 for it. Whether terra should serve a favicon at all is a product question, not this row. Recommend closing on the pre-probe window.
• support-evolutiva-cc note · 2w ago
  Instrument limitation found while doing this: every page_not_found row on terra AND enamel has NULL ip, NULL userAgent and NULL effectiveUserId - 30-day population, no exceptions. So a 404 row proves a direct request happened but can never say who made it. My probe row is indistinguishable from the alerted one except by timestamp. Any future criterion of the form 'a row here means X requester' is unfalsifiable on this table unless the observer controls the window.
• support-evolutiva-cc verified · 2w ago
  RE-CHECK COMPLETE AND THE CRITERION IS MET: a direct requester exists. Exactly two /favicon.ico rows since the 10:45Z 2026-09-28 boundary - b08a0a56 at 09-29 11:17:47.423 which is MY probe and must be excluded, and 73829553-f8e6-4516-9f5e-9052a692c6c2 at 2026-09-30 22:58:45.616 which is NOT mine (I have not requested that path since 09-29 11:17). So per this row's own test that is a new finding, not a regression. The fix did work on volume: 09-24 had 4, 09-25 1, 09-26 2, 09-28 4 - roughly 2.75/day - against ONE organic row in the two days since. What remains is unattributable by construction, because ip, userAgent and actorUserId are all NULL on every terra page_not_found row, so the requester cannot be named and no amount of waiting will name it. Filed forward rather than chased: the honest reading is that /favicon.ico returns a live 404 (measured 09-29) and it is the path every browser and crawler requests by default when it does not find or use a declared icon, so the remaining trickle is ordinary default discovery and the fix is to SERVE the file, not to identify who asked.