feat(billing): adds balance check job managing#2272
Conversation
WalkthroughWallet balance auto-reload functionality is added via a new WalletBalanceReloadCheck job type, handler, and database schema extension. The WalletSettingService integrates JobQueueService to schedule and cancel auto-reload jobs based on settings changes. Core services (JobQueueService, DomainEventsService, TxService) are enhanced with job cancellation, optional enqueue parameters, and generic transaction support. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant WalletSettingsService
participant TxService
participant JobQueueService
participant Repository
participant DomainEventsService
Client->>WalletSettingsService: upsertWalletSetting(userId, settings)
activate WalletSettingsService
WalletSettingsService->>TxService: transaction()
activate TxService
alt autoReloadEnabled changed to true
WalletSettingsService->>Repository: get existing setting
WalletSettingsService->>JobQueueService: enqueue(WalletBalanceReloadCheck)
JobQueueService-->>WalletSettingsService: return jobId
WalletSettingsService->>Repository: updateById(autoReloadJobId: jobId)
else autoReloadEnabled changed to false
WalletSettingsService->>JobQueueService: cancel(jobId)
WalletSettingsService->>Repository: updateById(autoReloadJobId: null)
end
TxService-->>WalletSettingsService: return result
deactivate TxService
WalletSettingsService-->>Client: return publicSetting (without autoReloadJobId)
deactivate WalletSettingsService
sequenceDiagram
participant JobQueue as pg-boss
participant JobQueueService
participant Handler as WalletBalanceReloadCheckHandler
participant Logger
JobQueue->>JobQueueService: job ready (WalletBalanceReloadCheck)
activate JobQueueService
JobQueueService->>Handler: handle()
activate Handler
Note over Handler: (placeholder: no-op)
Handler-->>JobQueueService: return
deactivate Handler
JobQueueService->>Logger: log JOB_COMPLETED
deactivate JobQueueService
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
apps/api/drizzle/0021_strange_madripoor.sql (1)
1-1: Consider adding an index on job_id for job cancellation queries.If the application will query wallet_settings by job_id when canceling jobs, an index would improve performance.
Apply this diff if job_id queries are expected:
ALTER TABLE "wallet_settings" ADD COLUMN "job_id" uuid; +CREATE INDEX "wallet_settings_job_id_idx" ON "wallet_settings"("job_id");apps/api/src/core/services/job-queue/job-queue.service.ts (1)
39-45: Job queue policy propagation and cancel API look consistentPassing
handler.policyintocreateQueueand exposingJobQueueService.cancel(name, id)keeps queue configuration and lifecycle cleanly encapsulated, and the logging is in line with the rest of the service. If you want to be extra defensive, you could (optionally) omit thepolicyfield when it’sundefined, or add error logging aroundpgBoss.cancelfailures, but the current implementation is perfectly acceptable.Also applies to: 95-102, 205-209
apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts (1)
2-19: Tests give good coverage of the new job lifecycle; a couple of minor polish opportunitiesThe spec nicely exercises:
- Public surface behavior (
getWalletSetting/upsertWalletSettingomittingautoReloadJobId).- Create vs update paths, including the duplicate-key retry case.
- Scheduling on enable (enqueue + persisting
autoReloadJobId) and cancellation on disable viajobQueueService.cancel.- The validation rules around
autoReloadEnabled, threshold, and amount.Two small nits you might consider (optional):
- In a couple of tests (e.g., “updates existing wallet setting”), the randomly generated
autoReloadEnabled/autoReloadJobIdon the seeded setting don’t affect assertions, but can make the setup slightly harder to reason about. Explicitly fixing those flags in the overrides when they matter would make the intent clearer.- Expectations currently use
WalletBalanceReloadCheck.namefor the queue name; if you later centralize the job name (e.g., via theJOB_NAMEsymbol or the event instance’sname), these tests will need to be adjusted to avoid drifting from the implementation.Overall, the test coverage around job enqueue/cancel behavior looks solid.
Also applies to: 23-69, 70-106, 172-203, 205-232, 276-308
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (1)
122-149: Auto‑reload scheduling/cancellation behavior is sound; consider tightening the transition and job namingThe scheduling helpers are nicely factored:
arrangeSchedulecentralizes the state transition logic,scheduleensures at most one job per setting by canceling any existing job and overwritingautoReloadJobId, anddeleteWalletSettingtakes care of canceling jobs when rows are removed.A couple of small, future‑proofing tweaks you might consider:
In
arrangeSchedule, you currently cancel whenever!next?.autoReloadEnabled && next?.autoReloadJobId. To make the intent clearer and more robust to future changes (e.g., if you ever start nullingautoReloadJobIdon disable), you could express this explicitly as “enabled → disabled” and pick the job id from either side, e.g.:const jobIdToCancel = prev?.autoReloadJobId ?? next?.autoReloadJobId; if (prev?.autoReloadEnabled && !next?.autoReloadEnabled && jobIdToCancel) { await this.jobQueueService.cancel(WalletBalanceReloadCheck.name, jobIdToCancel); }Queue naming currently relies on
WalletBalanceReloadCheck.nameinscheduleanddeleteWalletSetting. That matchesWalletBalanceReloadCheck[JOB_NAME]today, but if the class name and job name ever diverge, cancellations and singleton keys could silently drift. Deriving the name from the event’snameproperty or from theJOB_NAMEsymbol (e.g.,WalletBalanceReloadCheck[JOB_NAME]or a shared constant) would keep these call sites tied to the canonical job name.Optionally, you could also assert that
createdJobId === jobIdinschedulefor extra safety, though withoptions.idset that should already hold.Also applies to: 150-160
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
apps/api/drizzle/0021_strange_madripoor.sql(1 hunks)apps/api/drizzle/meta/0021_snapshot.json(1 hunks)apps/api/drizzle/meta/_journal.json(1 hunks)apps/api/src/app/providers/jobs.provider.ts(2 hunks)apps/api/src/billing/events/wallet-balance-reload-check.ts(1 hunks)apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts(1 hunks)apps/api/src/billing/services/wallet-balance-reload-check/wallet-balance-reload-check.handler.ts(1 hunks)apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts(6 hunks)apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts(3 hunks)apps/api/src/core/services/domain-events/domain-events.service.ts(2 hunks)apps/api/src/core/services/job-queue/job-queue.service.spec.ts(2 hunks)apps/api/src/core/services/job-queue/job-queue.service.ts(3 hunks)apps/api/src/core/services/tx/tx.service.ts(1 hunks)apps/api/src/provider/services/provider/provider.service.spec.ts(3 hunks)apps/api/test/functional/wallet-settings.spec.ts(0 hunks)apps/api/test/seeders/wallet-setting.seeder.ts(1 hunks)apps/api/test/services/wallet-testing.service.ts(1 hunks)
💤 Files with no reviewable changes (1)
- apps/api/test/functional/wallet-settings.spec.ts
🧰 Additional context used
🧠 Learnings (6)
📚 Learning: 2025-10-15T16:39:55.348Z
Learnt from: jzsfkzm
Repo: akash-network/console PR: 2039
File: apps/deploy-web/tests/ui/change-wallets.spec.ts:4-10
Timestamp: 2025-10-15T16:39:55.348Z
Learning: In the Akash Console E2E tests using the context-with-extension fixture, the first wallet is automatically created during fixture setup via `importWalletToLeap` in `apps/deploy-web/tests/ui/fixture/wallet-setup.ts`, so tests that call `frontPage.createWallet()` are creating a second wallet to test wallet switching functionality.
Applied to files:
apps/api/test/services/wallet-testing.service.tsapps/api/src/provider/services/provider/provider.service.spec.tsapps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts
📚 Learning: 2025-07-30T10:18:24.469Z
Learnt from: baktun14
Repo: akash-network/console PR: 1750
File: apps/api/drizzle/meta/0017_snapshot.json:17-49
Timestamp: 2025-07-30T10:18:24.469Z
Learning: In the Akash Network console billing system, the `user_wallets.user_id` column can be NULL to support anonymous user wallets, allowing users to interact with the system before authentication. Multiple anonymous wallets with NULL user_id values are permitted by design.
Applied to files:
apps/api/drizzle/0021_strange_madripoor.sql
📚 Learning: 2025-06-08T03:07:13.871Z
Learnt from: stalniy
Repo: akash-network/console PR: 1436
File: apps/api/src/provider/repositories/provider/provider.repository.ts:79-90
Timestamp: 2025-06-08T03:07:13.871Z
Learning: The getProvidersHostUriByAttributes method in apps/api/src/provider/repositories/provider/provider.repository.ts already has comprehensive test coverage in provider.repository.spec.ts, including tests for complex HAVING clause logic with COUNT(*) FILTER (WHERE ...) syntax, signature conditions (anyOf/allOf), and glob pattern matching.
Applied to files:
apps/api/src/provider/services/provider/provider.service.spec.ts
📚 Learning: 2025-05-28T20:42:58.200Z
Learnt from: jzsfkzm
Repo: akash-network/console PR: 1372
File: apps/api/src/dashboard/services/stats/stats.service.ts:0-0
Timestamp: 2025-05-28T20:42:58.200Z
Learning: The user successfully implemented CosmosHttpService with retry logic using axiosRetry, exponential backoff, and proper error handling for Cosmos API calls, replacing direct axios usage in StatsService.
Applied to files:
apps/api/src/provider/services/provider/provider.service.spec.ts
📚 Learning: 2025-11-19T15:15:07.283Z
Learnt from: ygrishajev
Repo: akash-network/console PR: 2254
File: apps/api/test/functional/sign-and-broadcast-tx.spec.ts:4-4
Timestamp: 2025-11-19T15:15:07.283Z
Learning: In the Akash Network Console project, when tests use native Node.js fetch (available in Node 18+), fetch-mock should be used for HTTP mocking instead of nock, as nock does not support intercepting native fetch calls. This applies to apps/api/test/functional/sign-and-broadcast-tx.spec.ts and any other tests using native fetch.
Applied to files:
apps/api/src/provider/services/provider/provider.service.spec.ts
📚 Learning: 2025-09-04T04:21:26.067Z
Learnt from: stalniy
Repo: akash-network/console PR: 1868
File: apps/api/src/app/services/trial-deployment-lease-created/trial-deployment-lease-created.handler.ts:73-76
Timestamp: 2025-09-04T04:21:26.067Z
Learning: The apps/api codebase consistently uses .toISOString() for startAfter values when scheduling jobs with JobQueueService to ensure UTC timezone consistency. This pattern is used throughout trial-started.handler.ts, trial-deployment-lease-created.handler.ts and other job scheduling code. Do not suggest changing to Date objects as ISO strings provide explicit UTC representation for database storage.
Applied to files:
apps/api/src/app/providers/jobs.provider.ts
🧬 Code graph analysis (5)
apps/api/src/billing/events/wallet-balance-reload-check.ts (2)
apps/api/src/core/services/job-queue/job-queue.service.ts (2)
Job(186-194)JOB_NAME(198-198)apps/api/src/core/services/domain-events/domain-events.service.ts (1)
JOB_NAME(6-6)
apps/api/src/billing/services/wallet-balance-reload-check/wallet-balance-reload-check.handler.ts (2)
apps/api/src/core/services/job-queue/job-queue.service.ts (1)
JobHandler(205-210)apps/api/src/billing/events/wallet-balance-reload-check.ts (1)
WalletBalanceReloadCheck(5-15)
apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts (1)
apps/api/src/billing/events/wallet-balance-reload-check.ts (1)
WalletBalanceReloadCheck(5-15)
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (4)
apps/api/src/billing/repositories/wallet-settings/wallet-settings.repository.ts (1)
WalletSettingOutput(19-22)apps/api/src/core/services/tx/tx.service.ts (1)
WithTransaction(33-45)apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts (1)
WalletSetting(7-37)apps/api/src/billing/events/wallet-balance-reload-check.ts (1)
WalletBalanceReloadCheck(5-15)
apps/api/src/core/services/domain-events/domain-events.service.ts (2)
apps/api/src/core/services/job-queue/job-queue.service.ts (2)
Job(186-194)EnqueueOptions(212-212)packages/logging/src/services/logger/logger.service.ts (1)
error(141-143)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (13)
apps/api/drizzle/meta/_journal.json (1)
152-158: LGTM!The journal entry correctly documents the new migration with proper sequencing and metadata.
apps/api/test/services/wallet-testing.service.ts (1)
40-40: LGTM!The mock correctly aligns with the updated DomainEventsService.publish signature that now returns
string | nullinstead ofvoid.apps/api/src/app/providers/jobs.provider.ts (2)
3-3: LGTM!The import follows the established pattern for job handlers.
21-22: LGTM!The WalletBalanceReloadCheckHandler is correctly registered in the job queue service, following the existing handler registration pattern.
apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts (1)
29-29: LGTM!The autoReloadJobId field correctly maps to the new job_id database column, with appropriate nullable semantics for tracking optional background jobs.
apps/api/src/core/services/job-queue/job-queue.service.spec.ts (2)
1-1: LGTM!The faker import enables UUID generation for the new cancel tests.
108-123: LGTM!The cancel test suite provides appropriate coverage by verifying both the pgBoss.cancel invocation and the JOB_CANCELLED logging event, following the established testing pattern.
apps/api/src/core/services/tx/tx.service.ts (1)
19-19: LGTM! Good enhancement.Making the transaction method generic enables it to return values from the callback while remaining backward compatible with existing void-returning usage.
apps/api/test/seeders/wallet-setting.seeder.ts (1)
13-13: LGTM!The autoReloadJobId field is correctly added to the test data generator, aligning with the schema changes and providing appropriate test coverage.
apps/api/drizzle/meta/0021_snapshot.json (1)
334-451: wallet_settings snapshot (includingjob_id) aligns with model/schema changesThe
wallet_settingstable definition, including the new nullablejob_idUUID column and existingwallet_iduniqueness /user_idindex, matches the TypeScript model schema and how the service usesautoReloadJobId. As this file is generated metadata, no manual adjustments are needed.apps/api/src/billing/events/wallet-balance-reload-check.ts (1)
1-15: WalletBalanceReloadCheck event wiring looks correctThe event cleanly implements
Jobwith a stableJOB_NAME-basedname, a versioned payload, and a minimaldatashape (userId) that matches how the scheduler uses it. No changes needed here.apps/api/src/core/services/domain-events/domain-events.service.ts (1)
4-8: DomainEventsService publish API is consistent with the job queue changesAligning
DomainEventwithJoband havingpublishreturn the underlying enqueue id (ornullon failure) makes the domain‑events layer a thin, predictable wrapper overJobQueueService.enqueue, while still logging failures. Just ensure any callers that care about delivery treat anullreturn as a soft failure.Also applies to: 18-29
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (1)
27-39: Upsert flow and validation for wallet settings look well-structuredThe new
getWalletSetting/upsertWalletSettingdesign is clean:
- Public responses intentionally omit
autoReloadJobId, keeping internal job bookkeeping out of the API.upsertWalletSettinguses a clear update‑then‑create pattern, with a duplicate‑key retry path that falls back toupdateand asserts success.validatecorrectly pulls threshold/amount from either the incoming settings or the existing record and enforces both whenautoReloadEnabledis true, matching the tests.This gives a solid foundation for managing auto‑reload configuration without leaking internal job details.
Also applies to: 41-75, 109-120
.../api/src/billing/services/wallet-balance-reload-check/wallet-balance-reload-check.handler.ts
Show resolved
Hide resolved
apps/api/src/provider/services/provider/provider.service.spec.ts
Outdated
Show resolved
Hide resolved
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2272 +/- ##
==========================================
- Coverage 47.64% 47.28% -0.37%
==========================================
Files 1034 1026 -8
Lines 29294 28994 -300
Branches 7624 7562 -62
==========================================
- Hits 13957 13709 -248
+ Misses 14949 14811 -138
- Partials 388 474 +86
*This pull request uses carry forward flags. Click here to find out more.
🚀 New features to boost your workflow:
|
ygrishajev
force-pushed
the
feature/wallet-setting
branch
from
1e7ea6a to
c1a1ccb
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (2)
41-120: Upsert, duplicate‑handling, and validation logic are robust (optional minor refactor only)The
@WithTransactionupsert pattern (updatefirst, thencreate, with a duplicate‑key retry that falls back toupdate) is race‑safe and easy to reason about.validatecorrectly enforces that bothautoReloadThresholdandautoReloadAmountare set when enabling auto‑reload, either from the payload or the existing setting, and thePostgresErrorguard for23505looks appropriate.If you later find the
{ prev?, next? }contract forupdate/createhard to follow, you could move to a small discriminated union (e.g.{ kind: "updated"; prev; next } | { kind: "created"; next } | { kind: "none" }) to make the control flow aroundmutationResultmore explicit, but that’s purely a readability tweak.
122-160: Scheduling/cancellation logic is sound; consider a small robustness tweak
arrangeScheduleandschedulecorrectly capture the state transitions:
- Transition from disabled → enabled (
!prev?.autoReloadEnabled && next?.autoReloadEnabled) schedules aWalletBalanceReloadCheckjob and persists its id.- Disabled state with an existing job id (
!next?.autoReloadEnabled && next?.autoReloadJobId) cancels the job.deleteWalletSettingcancels any stored job id in parallel with deleting the row, which is a sensible best‑effort compromise across two systems.
schedulealso asserts on the result ofjobQueueService.enqueue, so if enqueue fails the surrounding transaction can roll back the DB update toautoReloadJobId.Two optional tweaks you might consider:
- To guard against future divergence between the class name and the queue name, use the same job name constant that JobQueueService relies on (e.g.
WalletBalanceReloadCheck[JOB_NAME]) rather thanWalletBalanceReloadCheck.namewhen callingcanceland constructingsingletonKey.- In
arrangeSchedule, cancelling based onprev.autoReloadJobId(the job that was active before this mutation) rather thannext.autoReloadJobIdwould make the intent slightly clearer and more robust if a future change ever starts clearingautoReloadJobIdas part of the update.These are polish items; the current logic is functionally correct.
apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts (1)
44-105: Upsert and auto‑reload scheduling specs cover key paths; consider a delete‑path testThe updated
upsertWalletSettingtests now exercise the important behaviors:
- Updating an existing setting and asserting that the returned value matches the public shape (without
autoReloadJobId).- Creating a new setting when none exists, ensuring a
WalletBalanceReloadCheckjob is enqueued with the expectedsingletonKeyand id, and thatautoReloadJobIdis persisted viaupdateById.- Handling the duplicate‑key race by retrying through
update.- Enabling auto‑reload using existing threshold/amount, and cancelling the job when auto‑reload is disabled, with correct
WalletBalanceReloadCheckcancel arguments.These all look consistent with the service implementation and the JobQueueService contract.
Given that
deleteWalletSettingnow also cancels any existingautoReloadJobId, you might want to add a small spec that seeds a setting with a non‑nullautoReloadJobIdand verifiesjobQueueService.cancelis called on delete, to lock in that behavior.Also applies to: 107-136, 172-203, 205-232, 265-274
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
packages/net/src/generated/netConfigData.tsis excluded by!**/generated/**
📒 Files selected for processing (16)
apps/api/drizzle/0022_lazy_kabuki.sql(1 hunks)apps/api/drizzle/meta/0022_snapshot.json(1 hunks)apps/api/drizzle/meta/_journal.json(1 hunks)apps/api/src/app/providers/jobs.provider.ts(2 hunks)apps/api/src/billing/events/wallet-balance-reload-check.ts(1 hunks)apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts(1 hunks)apps/api/src/billing/services/wallet-balance-reload-check/wallet-balance-reload-check.handler.ts(1 hunks)apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts(6 hunks)apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts(3 hunks)apps/api/src/core/services/domain-events/domain-events.service.ts(2 hunks)apps/api/src/core/services/job-queue/job-queue.service.spec.ts(2 hunks)apps/api/src/core/services/job-queue/job-queue.service.ts(3 hunks)apps/api/src/core/services/tx/tx.service.ts(1 hunks)apps/api/test/functional/wallet-settings.spec.ts(0 hunks)apps/api/test/seeders/wallet-setting.seeder.ts(1 hunks)apps/api/test/services/wallet-testing.service.ts(1 hunks)
💤 Files with no reviewable changes (1)
- apps/api/test/functional/wallet-settings.spec.ts
✅ Files skipped from review due to trivial changes (1)
- apps/api/drizzle/meta/0022_snapshot.json
🚧 Files skipped from review as they are similar to previous changes (7)
- apps/api/test/services/wallet-testing.service.ts
- apps/api/src/billing/services/wallet-balance-reload-check/wallet-balance-reload-check.handler.ts
- apps/api/src/core/services/job-queue/job-queue.service.ts
- apps/api/src/core/services/tx/tx.service.ts
- apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts
- apps/api/test/seeders/wallet-setting.seeder.ts
- apps/api/src/billing/events/wallet-balance-reload-check.ts
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-15T16:39:55.348Z
Learnt from: jzsfkzm
Repo: akash-network/console PR: 2039
File: apps/deploy-web/tests/ui/change-wallets.spec.ts:4-10
Timestamp: 2025-10-15T16:39:55.348Z
Learning: In the Akash Console E2E tests using the context-with-extension fixture, the first wallet is automatically created during fixture setup via `importWalletToLeap` in `apps/deploy-web/tests/ui/fixture/wallet-setup.ts`, so tests that call `frontPage.createWallet()` are creating a second wallet to test wallet switching functionality.
Applied to files:
apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts
📚 Learning: 2025-09-04T04:21:26.067Z
Learnt from: stalniy
Repo: akash-network/console PR: 1868
File: apps/api/src/app/services/trial-deployment-lease-created/trial-deployment-lease-created.handler.ts:73-76
Timestamp: 2025-09-04T04:21:26.067Z
Learning: The apps/api codebase consistently uses .toISOString() for startAfter values when scheduling jobs with JobQueueService to ensure UTC timezone consistency. This pattern is used throughout trial-started.handler.ts, trial-deployment-lease-created.handler.ts and other job scheduling code. Do not suggest changing to Date objects as ISO strings provide explicit UTC representation for database storage.
Applied to files:
apps/api/src/app/providers/jobs.provider.ts
🧬 Code graph analysis (3)
apps/api/src/core/services/domain-events/domain-events.service.ts (2)
apps/api/src/core/services/job-queue/job-queue.service.ts (2)
Job(186-194)EnqueueOptions(212-212)packages/logging/src/services/logger/logger.service.ts (1)
error(141-143)
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (4)
apps/api/src/billing/repositories/wallet-settings/wallet-settings.repository.ts (1)
WalletSettingOutput(19-22)apps/api/src/core/services/tx/tx.service.ts (1)
WithTransaction(33-45)apps/api/src/billing/model-schemas/wallet-setting/wallet-setting.schema.ts (1)
WalletSetting(7-37)apps/api/src/billing/events/wallet-balance-reload-check.ts (1)
WalletBalanceReloadCheck(5-15)
apps/api/src/core/services/job-queue/job-queue.service.spec.ts (1)
apps/api/src/core/services/job-queue/job-queue.service.ts (1)
setup(172-179)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: test-build
- GitHub Check: validate / validate-app
- GitHub Check: test-build
- GitHub Check: Validate local packages
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (6)
apps/api/src/core/services/job-queue/job-queue.service.spec.ts (1)
1-1: Cancel flow test and faker usage look correctThe new test cleanly exercises
JobQueueService.cancel, asserting both the underlyingpgBoss.cancelcall and theJOB_CANCELLEDlog payload using a UUID fromfakercaptured in a local variable, so there’s no flakiness. No changes needed.Also applies to: 108-123
apps/api/src/app/providers/jobs.provider.ts (1)
3-3: WalletBalanceReloadCheckHandler registration is consistentThe new
WalletBalanceReloadCheckHandleris correctly imported and registered withJobQueueServicealongside existing handlers, preserving the existing ordering while wiring the new job type into the startup flow.Also applies to: 21-23
apps/api/drizzle/0022_lazy_kabuki.sql (1)
1-1: Schema change forwallet_settings.auto_reload_job_idis alignedAdding a nullable
uuidauto_reload_job_idcolumn matches the model/schema used to track scheduled auto‑reload jobs and won’t break existing rows. Looks good.apps/api/drizzle/meta/_journal.json (1)
153-165: Journal entry for migration0022_lazy_kabukiis consistentThe new entry at
idx: 22with tag0022_lazy_kabukiand version"7"cleanly extends the journal after0021_brave_warpath; metadata is coherent with the new SQL migration.apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts (1)
4-11: Auth/job‑queue wiring and public wallet setting shape look correctInjecting
AuthServiceandJobQueueServiceintoWalletSettingServiceand strippingautoReloadJobIdfromgetWalletSetting’s return value keeps the public API free of job‑queue implementation details while still enforcing access control viaaccessibleBy. No functional issues here.Also applies to: 20-25, 27-39
apps/api/src/billing/services/wallet-settings/wallet-settings.service.spec.ts (1)
2-6: UUID mocking and JobQueueService wiring in test setup look goodMocking
uuid.v4to return a deterministicjobIdand exposing bothjobQueueServiceandjobIdfromsetuplets the specs assert the exactenqueueoptions and persistedautoReloadJobIdwithout randomness. DerivingpublicSettingby omittingautoReloadJobIdfrom the seededwalletSettingalso keeps expectations in sync with the service’s newOmit<..., "autoReloadJobId">return types.Also applies to: 8-11, 17-19, 276-308
apps/api/src/billing/services/wallet-settings/wallet-settings.service.ts
Show resolved
Hide resolved
| id: jobId | ||
| }); | ||
|
|
||
| assert(createdJobId, 500, "Failed to schedule wallet balance reload check"); |
There was a problem hiding this comment.
issue(blocking): you are throwing outside transaction, right? and this means that wallet settings will have a reference to a job which was not created
There was a problem hiding this comment.
it is in tx. this is an internal method called by a method wrapped in a transaction
2 participants
refs #1779
Summary by CodeRabbit
Release Notes
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.