Pass ENOTIFY_INTERNAL_TOKEN through to vapi - #1710
Conversation
Gap in my own change. ecency/vision-api#91 reads ENOTIFY_INTERNAL_TOKEN to unlock a user's own complete notification feed from enotify, but nothing ever set it: the variable was never added to the compose files or forwarded by the deploy workflows, so vapi would have read an empty string forever. Wired exactly like SSR_INTERNAL_SECRET, which is the most recent secret of the same shape: declared on the vapi service in both compose files, and forwarded in all three places each deploy job needs it (the env map, the ssh envs list and the export before the stack deploy), across both regions in master.yml and staging. Only the vapi service gets it. The web service does not talk to enotify. Setting it by hand on the running service would not have worked either: a stack deploy from this repo resets the full service spec of every service in the stack, so it has to live here. Requires the ENOTIFY_INTERNAL_TOKEN repository secret, matching [APP] INTERNAL_TOKEN in enotify's config.ini. enotify fails closed, so until both sides carry the same value every user quietly loses favorites, bookmarks, Points transfers and the aggregates from their own notification list.
|
ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing |
PR Summary by QodoForward ENOTIFY_INTERNAL_TOKEN to vapi deployments
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
Code Review by Qodo
1. Missing token deploys silently
|
| # notification feed. enotify defaults to chain-derived activity only and | ||
| # fails closed, so unset means every user silently loses favorites, | ||
| # bookmarks, Points transfers and the aggregates from their own list. | ||
| - ENOTIFY_INTERNAL_TOKEN |
There was a problem hiding this comment.
1. Missing token deploys silently 🐞 Bug ☼ Reliability
The bare Compose passthrough accepts an absent or empty ENOTIFY_INTERNAL_TOKEN, so deployments succeed while vapi silently omits favorites, bookmarks, Points transfers, and notification aggregates. This also lets a later missing-secret deployment reset a previously working service to the degraded state without any CI failure.
Agent Prompt
## Issue description
An unset or empty `ENOTIFY_INTERNAL_TOKEN` currently passes through Compose without failing, allowing a green deployment that disables parts of users' notification feeds.
## Issue Context
Both production and staging Compose configurations describe this token as necessary for the complete feed. Use required-variable interpolation, consistent with the existing `HIVESEARCHER_ORIGIN_IP` handling, so Compose rendering fails before stack deployment when the token is absent or empty.
## Fix Focus Areas
- apps/web/docker-compose.production.yml[23-27]
- apps/web/docker-compose.yml[23-27]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d343c27d6e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| export SEO_CRON_SECRET=$SEO_CRON_SECRET | ||
| export TURNSTILE_SECRET=$TURNSTILE_SECRET | ||
| export SSR_INTERNAL_SECRET=$SSR_INTERNAL_SECRET | ||
| export ENOTIFY_INTERNAL_TOKEN=$ENOTIFY_INTERNAL_TOKEN |
There was a problem hiding this comment.
Reject an empty enotify token before deploying
When ENOTIFY_INTERNAL_TOKEN is missing from the repository secrets, this export still succeeds and the production compose render deploys vapi with an empty token. As the new compose comment states, vapi then fails closed and silently omits favorites, bookmarks, Points transfers, and aggregates for every user, while the workflow remains green. Add a nonempty preflight check in both production deploy jobs, analogous to the adjacent newsletter checks; staging should at least fail or warn explicitly as intended.
Useful? React with 👍 / 👎.
|
Warning Review limit reachedNext included review available in 34 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Superseded by ecency/enotify-py#23, which drops the shared secret entirely in favour of trusting the private network position that api-proxy already uses. No repository secret, no compose change, no deploy ordering to get wrong. Reusing Closing this unmerged unless you would rather keep the token path as the primary. |
|
Note for anyone reading the two bot findings above: both flag that a missing ecency/enotify-py#23 removes the secret entirely in favour of trusting the specific api-proxy host, so there is no token to forget, no repository secret, no compose passthrough and no deploy ordering at all. This PR should be closed unmerged rather than fixed. |
Closes a gap in my own change, found while working out where the secret actually needs to be set.
ecency/vision-api#91 (merged, deployed) reads
ENOTIFY_INTERNAL_TOKENto unlock a user's own complete notification feed from enotify. But nothing ever set it: the variable was never added to the compose files or forwarded by the deploy workflows, so vapi would have read an empty string forever and never sent the header.What this does
Wired exactly like
SSR_INTERNAL_SECRET, the most recent secret of the same shape:docker-compose.production.ymldocker-compose.yml(staging)master.ymlenvs:list, andexport— in both the EU and US deploy jobsstaging.ymlOnly vapi gets it. The web service does not talk to enotify.
Setting it by hand on the running service would not have worked either: a stack deploy from this repo resets the full service spec of every service in the stack, so it has to live here.
Required before this helps
An
ENOTIFY_INTERNAL_TOKENrepository secret, matching[APP] INTERNAL_TOKENin enotify'sconfig.ini.Deploy order: set the enotify config value and this repository secret → deploy this → deploy enotify.
Verification
All four YAML files parse. Asserted that all three wiring points are present in each deploy job (2 in master, 1 in staging), that the vapi service carries the variable, and that the web service does not.