Log sources are doubled (`<svc>_<svc>`) for every service's main action #162

New issue

Open

opened 2026-06-22 13:36:14 +00:00 by mahmoud · 0 comments

mahmoud commented

2026-06-22 13:36:14 +00:00

Owner

Symptom

Every service's captured logs are stored/listed under a doubled source name, e.g.:

core.hero_browser_server_hero_browser_server.<pid>
core.hero_browser_admin_hero_browser_admin.<pid>
core.hero_components_hero_components.<pid>
core.slides_slides.<pid>

They should read hero_browser_server, hero_browser_admin, hero_components, slides, etc. This affects every service (the main action), and it breaks prefix/"All" filtering in admin log viewers (the UI ends up needing per-service log_source overrides, e.g. hero_components maps hero_whiteboard → whiteboard).

Root cause (chain, with line refs)

crates/hero_proc_server/src/service/define.rs:132 — a service's main action is named identically to the service ("= service name by convention"):
```
let main_action_name = name.to_string();
```
So service hero_browser_server gets a main action also called hero_browser_server.
crates/hero_proc_server/src/supervisor/mod.rs:397 — the supervised job's action is composed as <service>.<action>:
```
action: format!("{}.{}", name, action_name),
```
For the main action that's hero_browser_server.hero_browser_server.
crates/hero_proc_server/src/logging/adapter.rs build_hero_src — collapses the dotted action into one underscored segment (to keep the hero_log src at exactly three dotted parts context.src.jobid):
hero_browser_server.hero_browser_server → hero_browser_server_hero_browser_server.
Final src: core.hero_browser_server_hero_browser_server.<pid>.
(See the existing unit test build_hero_src_collapses_dotted_action: action "hero_router.hero_router" → "core.hero_router_hero_router.11".)

The log src is read in supervisor/executor.rs (let src = job.action.clone(); let log_src = job_log_src(&ctx, &src, job_id);).

Suggested fix (dedupe equal segments)

Either:

supervisor/mod.rs:397 — don't repeat when the segments are equal:

action: if name == action_name { name.clone() } else { format!("{}.{}", name, action_name) },

or build_hero_src — collapse a X.X middle segment to X.

⚠️ Blast radius — must keep writer and reader in sync

The src string is the storage key. The reader path (logging/filter.rs filter_to_query + build_hero_src on the query side) must produce the byte-identical src or log retrieval silently misses the directory. So:

Fix the writer and the reader together, with matching unit tests (update build_hero_src_collapses_dotted_action and the filter dual).
Existing stored logs use the old doubled form — decide whether to migrate them or accept that pre-fix logs keep the old key.
Verify log retrieval still works end-to-end for a few services after the change.

Because this touches every service's log lookup, it should be a deliberate, tested change rather than a drive-by.

Notes

Not specific to any one service or to the oschema migration — it's the <service>.<action> job-naming convention biting whenever the main action name equals the service name (always).
Discovered while migrating hero_browser_server to the oschema stack; the hero_components admin had previously worked around it with per-service log_source overrides.

## Symptom Every service's captured logs are stored/listed under a **doubled** source name, e.g.: ``` core.hero_browser_server_hero_browser_server.<pid> core.hero_browser_admin_hero_browser_admin.<pid> core.hero_components_hero_components.<pid> core.slides_slides.<pid> ``` They should read `hero_browser_server`, `hero_browser_admin`, `hero_components`, `slides`, etc. This affects **every** service (the main action), and it breaks prefix/"All" filtering in admin log viewers (the UI ends up needing per-service `log_source` overrides, e.g. hero_components maps `hero_whiteboard` → `whiteboard`). ## Root cause (chain, with line refs) 1. **`crates/hero_proc_server/src/service/define.rs:132`** — a service's main action is named identically to the service ("= service name by convention"): ```rust let main_action_name = name.to_string(); ``` So service `hero_browser_server` gets a main action also called `hero_browser_server`. 2. **`crates/hero_proc_server/src/supervisor/mod.rs:397`** — the supervised job's `action` is composed as `<service>.<action>`: ```rust action: format!("{}.{}", name, action_name), ``` For the main action that's `hero_browser_server.hero_browser_server`. 3. **`crates/hero_proc_server/src/logging/adapter.rs` `build_hero_src`** — collapses the dotted action into one underscored segment (to keep the hero_log src at exactly three dotted parts `context.src.jobid`): `hero_browser_server.hero_browser_server` → `hero_browser_server_hero_browser_server`. Final src: `core.hero_browser_server_hero_browser_server.<pid>`. (See the existing unit test `build_hero_src_collapses_dotted_action`: action `"hero_router.hero_router"` → `"core.hero_router_hero_router.11"`.) The log src is read in `supervisor/executor.rs` (`let src = job.action.clone(); let log_src = job_log_src(&ctx, &src, job_id);`). ## Suggested fix (dedupe equal segments) Either: - **`supervisor/mod.rs:397`** — don't repeat when the segments are equal: ```rust action: if name == action_name { name.clone() } else { format!("{}.{}", name, action_name) }, ``` - or **`build_hero_src`** — collapse a `X.X` middle segment to `X`. ## ⚠️ Blast radius — must keep writer and reader in sync The src string is the **storage key**. The reader path (`logging/filter.rs` `filter_to_query` + `build_hero_src` on the query side) must produce the **byte-identical** src or log retrieval silently misses the directory. So: - Fix the writer **and** the reader together, with matching unit tests (update `build_hero_src_collapses_dotted_action` and the filter dual). - Existing stored logs use the old doubled form — decide whether to migrate them or accept that pre-fix logs keep the old key. - Verify log retrieval still works end-to-end for a few services after the change. Because this touches every service's log lookup, it should be a deliberate, tested change rather than a drive-by. ## Notes - Not specific to any one service or to the oschema migration — it's the `<service>.<action>` job-naming convention biting whenever the main action name equals the service name (always). - Discovered while migrating `hero_browser_server` to the oschema stack; the hero_components admin had previously worked around it with per-service `log_source` overrides.