Fix execution bug

[viceroypenguin]

Summary by CodeRabbit

• Bug Fixes
  • Storage initialization now runs even when job scheduling is disabled. In that state, scheduler loops remain stopped, so disabling scheduling does not prevent storage from being initialized.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 60ec9439-6b7a-4acc-909b-78ef11b46b67

📥 Commits

Reviewing files that changed from the base of the PR and between 7558636 and 06f92f0.

📒 Files selected for processing (1)

• src/Immediate.Jobs.Shared/Internals/JobSchedulingService.cs

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

JobSchedulingService.ExecuteAsync now initializes storage before checking whether scheduling is enabled. If scheduling is disabled, execution returns after initialization and does not start the scheduler loops.

Changes

Scheduling initialization

Layer / File(s)	Summary
Initialize storage before the enabled check src/Immediate.Jobs.Shared/Internals/JobSchedulingService.cs	ExecuteAsync calls InitializeAsync before checking whether scheduling is enabled. When scheduling is disabled, it returns after initialization.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 06f92

No merge-blocking issue is established; scheduling remains disabled while storage initializes.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 06f92

Disabling scheduling still prevents scheduler loops from starting, but it no longer prevents startup from accessing storage or changing recurring schedules. That matters for deployments relying on disabled scheduling during maintenance or rollback. No new attacker-accessible path was established.

Retained concerns

• Medium · reliability · observed: Disabled scheduling now permits recurring-schedule reconciliation against durable storage. A disabled deployment can update or remove code-defined schedules, so disabling scheduler loops alone is not a no-write maintenance or rollback state.

Security review details

Security Blast Radius

• inferred — The changed disabled-startup path can reach whichever storage provider is configured for this service and its durable recurring schedules. Tenant, cross-service, and deployment-wide exposure are not established.

Trust Boundaries and Controls

• observed — The enabled check still gates scheduler loops, but no longer gates storage initialization or recurring-schedule reconciliation. The inspected changed path does not show an attacker-controlled input or an authentication or authorization transition.

Resilience and Maintainability Implications

• inferred — Cancellation during Redis schedule reconciliation can leave some upserts completed before obsolete entries are removed. This behavior predates the PR, but the reconciliation path is newly reached when scheduling is disabled.

Hardening Proposals

• proposed — Specify whether disabled scheduling is intended to permit durable reconciliation during maintenance and rollback. If a no-write disabled state is required, give that state an explicit control distinct from the scheduler-loop switch.

🚥 Pre-merge checks | ✅ 4 | ❓ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title refers to a real bug fix, but it does not identify the scheduling initialization behavior changed by the pull request.	Use a specific title such as "Initialize storage before checking scheduler availability".

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coveralls]

Coverage Report for CI Build 36476564399

Coverage decreased (-0.09%) to 88.956%

Details

• Coverage decreased (-0.09%) from the base build.
• Patch coverage: 1 of 1 lines across 1 file are fully covered (100%).
• 12 coverage regressions across 1 file.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

12 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
src/Immediate.Jobs.EntityFrameworkCore/EntityFrameworkCoreJobStorage.cs	12	91.16%

---

Coverage Stats

Relevant Lines:	13410
Covered Lines:	11929
Line Coverage:	88.96%
Coverage Strength:	2.88 hits per line

---

💛 - Coveralls