Changed member welcome email job to run based on config#19
Conversation
Code Review by Qodo
1. var member declaration
|
| const memberAddOptions = {...(options || {}), withRelated}; | ||
| let member; | ||
| if (this._labsService.isSet('welcomeEmails') && WELCOME_EMAIL_SOURCES.includes(source)) { | ||
| var member; |
There was a problem hiding this comment.
1. var member declaration 📘 Rule violation ✓ Correctness
• MemberRepository introduces a var declaration (var member;), which violates the requirement to use block-scoped let/const. • Using var can cause hoisting and scope-related bugs, reducing code safety and predictability.
Agent prompt
## Issue description
A `var` declaration was introduced (`var member;`), which violates the codebase requirement to use `let`/`const`.
## Issue Context
Using `var` can introduce hoisting and function-scope leakage, increasing the risk of subtle bugs.
## Fix Focus Areas
- ghost/core/core/server/services/members/members-api/repositories/MemberRepository.js[339-342]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| } | ||
|
|
||
| if (!hasScheduled.processOutbox && !process.env.NODE_ENV.startsWith('test')) { | ||
| if (hasScheduled.processOutbox && !process.env.NODE_ENV.startsWith('test')) { |
There was a problem hiding this comment.
2. node_env.startswith unguarded 📘 Rule violation ⛯ Reliability
• The scheduling condition calls process.env.NODE_ENV.startsWith('test') without guarding against
NODE_ENV being undefined/null.
• In environments where NODE_ENV is not set, this can throw a runtime TypeError and prevent job
scheduling, reducing resilience.
Agent prompt
## Issue description
The code calls `process.env.NODE_ENV.startsWith('test')` without handling the case where `NODE_ENV` is unset, which can throw at runtime.
## Issue Context
In some deployments/tests, `NODE_ENV` may be undefined. The scheduling logic should behave safely without relying on implicit environment setup.
## Fix Focus Areas
- ghost/core/core/server/services/member-welcome-emails/jobs/index.js[11-25]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| if (hasScheduled.processOutbox && !process.env.NODE_ENV.startsWith('test')) { | ||
| jobsService.addJob({ | ||
| at: '0 */5 * * * *', | ||
| job: path.resolve(__dirname, 'process-outbox.js'), |
There was a problem hiding this comment.
3. Job never schedules 🐞 Bug ⛯ Reliability
• The job scheduling guard is inverted: it only schedules when hasScheduled.processOutbox is already true, but it starts false, so the job is never registered. • The service init calls scheduling once and then marks itself initialized, so welcome-email outbox processing never runs even when config is set. • Result: MemberCreatedEvent outbox entries (if created) will remain pending indefinitely, effectively disabling the feature.
Agent prompt
### Issue description
The member welcome email outbox processing job is never scheduled because the condition guarding `jobsService.addJob()` is inverted.
### Issue Context
`hasScheduled.processOutbox` starts as `false` and is only set to `true` inside the scheduling block. With the current condition (`if (hasScheduled.processOutbox && ...)`) the block is unreachable on first run.
### Fix Focus Areas
- ghost/core/core/server/services/member-welcome-emails/jobs/index.js[11-25]
### Suggested change
Change:
```js
if (hasScheduled.processOutbox && !process.env.NODE_ENV.startsWith('test')) {
```
To:
```js
if (!hasScheduled.processOutbox && !process.env.NODE_ENV.startsWith('test')) {
```
And keep `hasScheduled.processOutbox = true;` inside the block so it only schedules once.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
| var member; | ||
| const welcomeEmailConfig = config.get('memberWelcomeEmailTestInbox'); | ||
| if (welcomeEmailConfig || WELCOME_EMAIL_SOURCES.includes(source)) { | ||
| const runMemberCreation = async (transacting) => { |
There was a problem hiding this comment.
4. Outbox gating uses or 🐞 Bug ✓ Correctness
• MemberRepository.create() now creates a welcome-email outbox entry when `(welcomeEmailConfig || WELCOME_EMAIL_SOURCES.includes(source))`, which incorrectly creates outbox entries even when the config is missing (normal signups default to source member). • When the config is set, it also creates outbox entries for disallowed sources (import/admin/api) because welcomeEmailConfig alone makes the condition true. • This contradicts the updated unit/integration tests and can lead to unwanted/never-processed outbox growth (especially combined with the scheduling bug).
Agent prompt
### Issue description
MemberRepository currently creates `MemberCreatedEvent` outbox entries for welcome emails under incorrect conditions due to an OR check.
### Issue Context
- `WELCOME_EMAIL_SOURCES = ['member']`
- Default source is `member`
- The sender requires `memberWelcomeEmailTestInbox` to be set
- Tests expect: no outbox entry when config is missing; no outbox entry for disallowed sources
### Fix Focus Areas
- ghost/core/core/server/services/members/members-api/repositories/MemberRepository.js[339-378]
### Suggested change
Change:
```js
if (welcomeEmailConfig || WELCOME_EMAIL_SOURCES.includes(source)) {
```
To:
```js
if (welcomeEmailConfig && WELCOME_EMAIL_SOURCES.includes(source)) {
```
Optionally normalize `welcomeEmailConfig` to a boolean (`const welcomeEmailEnabled = !!config.get(...)`) to avoid treating empty strings as enabled.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Benchmark PR from qodo-benchmark#246