You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
bug: the link on the image in the daily email is a relative URL and therefore doesn't resolve. the URL should be absolute and link to the APOD site #51
The daily email wraps the APOD image in <a href="${data.hdurl || data.url}"> (src/services/apodService.js:25), linking directly to the raw image file on apod.nasa.gov.
Following that link lands on APOD's 403 Forbidden page for /apod/image/2609/MilkyWayMeteorLSTJeffDai.jpg (see the issue screenshot) — APOD blocks direct image-file access, so the link is unusable even when the URL itself is absolute.
Secondary gap: any genuinely relative href would survive untouched — the UTM-tracking pass in src/services/emailService.js wraps new URL(href) in a try/catch that silently skips non-absolute URLs instead of resolving them.
Change the image anchor to link to the APOD day page, not the image file: build the absolute page URL from data.date using the same ap<yyMMdd>.html pattern the scraper already uses (e.g. https://apod.nasa.gov/apod/ap260926.html). The native-video branch in the same file already does exactly this (~line 119). This matches the issue's ask: the URL should be absolute and link to the APOD site.
Interaction with APOD website is moving #47 (APOD moving to science.nasa.gov): if that migration changes the canonical day-page URL, this fix should consume the same URL builder — implement one apodPageUrl(date) helper used by both paths rather than a second hardcoded pattern.
Verification
npm test (vitest suite).
node preview_apod_email.js / generate_test_email.js: click the image in the generated email and confirm it opens the APOD day page, not a 403.
Add a regression test asserting every href in the generated email is absolute — today <a href="undefined"> is possible when both hdurl and url are missing.
Re-reviewed the #51 plan against current main (post-#47 migration) and implemented it in PR #54.
Re-review finding: the plan's original recommendation was to link the image to the APOD day page via the apYYMMDD.html pattern. That no longer holds — the #47 migration (PR #52) established that date-addressable day URLs 404 on science.nasa.gov. So the image now links to the canonical APOD home page instead, consistent with the native-video branch.
Added a shared apodPageUrl() helper in src/services/apodService.js; the image anchor uses it instead of the raw image-file URL (which 403'd). The native-video branch uses the same helper rather than a second hardcoded URL.
The plain-text View Image line points at the APOD page too.
Regression tests: image anchors at the APOD page, and every href in the generated HTML is absolute (guards the href=undefined gap when hdurl/url are missing).
Tests: 5/5 in apodService.test.js pass; full suite 37/38, with the single failure being a pre-existing network-dependent emailService test that also fails on unmodified main.
Quick check before doing anything further here: PR #54 (the re-reviewed implementation of this plan) was just closed with the note "this looked like a one-off error by the apod team. ignoring this change for now."
That reads like a decision to drop the fix, so I'm holding off on re-implementing. Should I close this issue as well, or keep it open in case the link problem turns out to be real and recurring?
Quick check before doing anything further on this ticket: PR #54 (which implemented the re-reviewed plan on 2026-09-27) was closed unmerged on 2026-09-30 with the note "this looked like a one-off error by the apod team. ignoring this change for now."
The thread has no further direction after that closure, so I can't tell whether the fix should be treated as dropped or re-implemented in a new PR. Holding off on any new implementation until you weigh in — @gtracy, could you confirm which way you'd like this to go?
Activity
gtracymuse commentedon Sep 26, 2026
Implementation Plan
Root cause
<a href="${data.hdurl || data.url}">(src/services/apodService.js:25), linking directly to the raw image file on apod.nasa.gov./apod/image/2609/MilkyWayMeteorLSTJeffDai.jpg(see the issue screenshot) — APOD blocks direct image-file access, so the link is unusable even when the URL itself is absolute.hrefwould survive untouched — the UTM-tracking pass insrc/services/emailService.jswrapsnew URL(href)in a try/catch that silently skips non-absolute URLs instead of resolving them.Affected components
src/services/apodService.js—mediaHtmlimage branch (line ~25).src/services/apodScraper.js(URL construction),src/services/emailService.js(UTM pass).Proposed fix
Change the image anchor to link to the APOD day page, not the image file: build the absolute page URL from
data.dateusing the sameap<yyMMdd>.htmlpattern the scraper already uses (e.g.https://apod.nasa.gov/apod/ap260926.html). The native-video branch in the same file already does exactly this (~line 119). This matches the issue's ask: the URL should be absolute and link to the APOD site.apodPageUrl(date)helper used by both paths rather than a second hardcoded pattern.Verification
npm test(vitest suite).node preview_apod_email.js/generate_test_email.js: click the image in the generated email and confirm it opens the APOD day page, not a 403.hrefin the generated email is absolute — today<a href="undefined">is possible when bothhdurlandurlare missing.gtracy commentedon Sep 27, 2026
@gtracymuse re-review the changes based on the current state of main and then implement your recommendation changes in a PR.
gtracymuse commentedon Sep 27, 2026
Re-reviewed the #51 plan against current main (post-#47 migration) and implemented it in PR #54.
Re-review finding: the plan's original recommendation was to link the image to the APOD day page via the apYYMMDD.html pattern. That no longer holds — the #47 migration (PR #52) established that date-addressable day URLs 404 on science.nasa.gov. So the image now links to the canonical APOD home page instead, consistent with the native-video branch.
What changed in PR #54:
Tests: 5/5 in apodService.test.js pass; full suite 37/38, with the single failure being a pre-existing network-dependent emailService test that also fails on unmodified main.
gtracymuse commentedon Sep 30, 2026
Quick check before doing anything further here: PR #54 (the re-reviewed implementation of this plan) was just closed with the note "this looked like a one-off error by the apod team. ignoring this change for now."
That reads like a decision to drop the fix, so I'm holding off on re-implementing. Should I close this issue as well, or keep it open in case the link problem turns out to be real and recurring?
gtracymuse commentedon Oct 1, 2026
Quick check before doing anything further on this ticket: PR #54 (which implemented the re-reviewed plan on 2026-09-27) was closed unmerged on 2026-09-30 with the note "this looked like a one-off error by the apod team. ignoring this change for now."
The thread has no further direction after that closure, so I can't tell whether the fix should be treated as dropped or re-implemented in a new PR. Holding off on any new implementation until you weigh in — @gtracy, could you confirm which way you'd like this to go?