fix: avoid dead render aggregation message #28

graham · 2026-09-14T23:35:40-05:00

graham commented

2026-09-14 23:35:40 -05:00

Fixes W11 from bugs.md.

InfoLive.Show.mount_valid/2 now guards the send(self(), :load_aggregations) with connected?/1, matching the PubSub subscription guard directly above it. On the dead render self() is the HTTP connection process with no handle_info clause, so the message previously sat in its mailbox across keep-alive requests. Connected LiveViews keep the existing refresh path unchanged.

Verification: focused info_live tests passed (57), full suite passed (2235), mix credo --strict, and commit hooks including Dialyzer passed.

Fixes W11 from bugs.md. `InfoLive.Show.mount_valid/2` now guards the `send(self(), :load_aggregations)` with `connected?/1`, matching the PubSub subscription guard directly above it. On the dead render `self()` is the HTTP connection process with no `handle_info` clause, so the message previously sat in its mailbox across keep-alive requests. Connected LiveViews keep the existing refresh path unchanged. Verification: focused info_live tests passed (57), full suite passed (2235), `mix credo --strict`, and commit hooks including Dialyzer passed.

graham added 1 commit

2026-09-14 23:35:41 -05:00

fix: avoid dead render aggregation message

Elixir CI / Dialyzer (pull_request) Successful in 41s

Details

skippy-bot/review Skippy review: clean — 1 non-blocking note open

Details

Elixir CI / Build and test (pull_request) Successful in 1m44s

Details

Elixir CI / Build and Push Docker Image (pull_request) Has been skipped

Details

1ccff69081

skippy-bot reviewed

2026-09-14 23:37:06 -05:00

skippy-bot left a comment

🤖 Skippy PR review

1 finding — none blocking.

Severity	Location	Issue
🔵 Suggestion	`lib/aprsme_web/live/info_live/show.ex:117`	Comment claims the aggregations are computed for the initial render — they are not

_{Reviewed 1ccff690812b. Comment skippy review to re-run.}

### 🤖 Skippy PR review **1 finding** — none blocking. | Severity | Location | Issue | | --- | --- | --- | | 🔵 Suggestion | `lib/aprsme_web/live/info_live/show.ex:117` | Comment claims the aggregations are computed for the initial render — they are not | <sub>Reviewed `1ccff690812b`. Comment `skippy review` to re-run.</sub>

lib/aprsme_web/live/info_live/show.ex Outdated

					
				@ -115,0 +114,4 @@

				    # Only a connected LiveView process handles :load_aggregations. On the

				    # dead render `self()` is the HTTP connection process, which has no

				    # handler — the message would sit in its mailbox across keep-alive

				    # requests. (The aggregations are computed above for the initial render;

🔵 Suggestion — Comment claims the aggregations are computed for the initial render — they are not

Nothing above this point computes the aggregations: lines 108-109 assign heard_by_stations: [] and stations_heard_by: [], and the only writer is handle_info(:load_aggregations, ...). So the dead render's HTML omits both sections entirely and they appear only after the connected mount fills them. Either say that plainly (the send is connected-only because the static render has no aggregation data), or, if JS-less clients/crawlers are meant to see those sections, compute them in mount/3 when not connected?(socket).

The guard itself is correct and matches the subscribe guard above.

**🔵 Suggestion — Comment claims the aggregations are computed for the initial render — they are not** Nothing above this point computes the aggregations: lines 108-109 assign `heard_by_stations: []` and `stations_heard_by: []`, and the only writer is `handle_info(:load_aggregations, ...)`. So the dead render's HTML omits both sections entirely and they appear only after the connected mount fills them. Either say that plainly (the send is connected-only because the static render has no aggregation data), or, if JS-less clients/crawlers are meant to see those sections, compute them in `mount/3` when `not connected?(socket)`. The guard itself is correct and matches the `subscribe` guard above.

skippy-bot marked this conversation as resolved

graham added 1 commit

2026-09-15 11:59:29 -05:00

fix: correct dead-render comment about aggregation data

skippy-bot/review Skippy review: clean — no open findings

Details

Elixir CI / Build and test (pull_request) Successful in 59s

Details

Elixir CI / Dialyzer (pull_request) Successful in 40s

Details

Elixir CI / Build and Push Docker Image (pull_request) Has been skipped

Details

4e1894483f

skippy-bot commented

2026-09-15 11:59:46 -05:00

First-time contributor

Resolved 1 of 1 earlier finding: the dead-render comment now says the two aggregation sections are omitted on the static render and only filled by the connected mount, which matches heard_by_stations/stations_heard_by being assigned [] at show.ex:108-109.

Nothing new in 1ccff690812b..4e1894483f50 (comment-only change).

Resolved 1 of 1 earlier finding: the dead-render comment now says the two aggregation sections are omitted on the static render and only filled by the connected mount, which matches `heard_by_stations`/`stations_heard_by` being assigned `[]` at `show.ex:108-109`. Nothing new in `1ccff690812b..4e1894483f50` (comment-only change).

graham merged commit cc49c6e4b6 into main

2026-09-15 16:33:22 -05:00

graham deleted branch fix/w11-dead-render-message

2026-09-15 16:33:22 -05:00

graham referenced this pull request from a commit

2026-09-15 16:33:24 -05:00

fix: avoid dead render aggregation message (#28)

Sign in to join this conversation.

No reviewers

No labels

No milestone

No project