fix(settlement): finalize suggestions and snooze logic end-to-end#309
Conversation
|
@mijinummi is attempting to deploy a commit to the olufunbiik's projects Team on Vercel. A member of the Team first needs to authorize it. |
📝 WalkthroughWalkthroughA comprehensive settlement feature has been introduced, including a TypeORM User entity with balance and snooze state, a database repository layer, business service logic for generating settlement suggestions and managing snooze windows, HTTP endpoints for the settlement API, and Stellar blockchain integration for balance verification. Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Controller
participant Service
participant Repository
participant Database
participant Stellar
Note over Client,Stellar: Settlement Suggestion Generation Flow
Client->>Controller: GET /suggestions
Controller->>Service: generateSuggestions()
Service->>Repository: findActiveParticipants()
Repository->>Database: Query users (snoozedUntil null or < now)
Database-->>Repository: Return active users
Repository-->>Service: User[] with balances
Service->>Service: Aggregate balances, determine status
Service-->>Controller: SettlementSuggestion[]
Controller-->>Client: JSON response
Note over Client,Repository: Settlement Snooze Management Flow
Client->>Controller: POST /snooze {userId, until}
Controller->>Service: snoozeSettlement(userId, date)
Service->>Repository: updateSnooze(userId, date)
Repository->>Database: UPDATE user.snoozedUntil
Database-->>Repository: Confirmation
Repository-->>Service: void
Service-->>Controller: Completion
Controller-->>Client: {success: true}
Note over Client,Stellar: Settlement Verification Flow
Client->>Controller: POST /verify {user, asset, amount}
Controller->>Service: verifySettlement(user, asset, amount)
Service->>Stellar: verifyBalance(accountId, asset, amount)
Stellar-->>Service: boolean result
Service-->>Controller: {verified: boolean}
Controller-->>Client: JSON response
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 11
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@backend/src/settlement/entities/user.entity.ts`:
- Around line 3-13: You added a second User entity class (class User) that maps
to the same "users" table, causing duplicate schema definitions; either remove
this duplicate entity and import the canonical User entity everywhere, or
rename/repurpose this entity and its `@Entity` name to avoid colliding with the
existing User model. Locate usages that import User from the settlement module
and change them to import the single canonical User export instead (or adjust
repository/service imports to the canonical model), and ensure only one entity
is registered with the "users" table so snoozedUntil and balances persist
consistently.
In `@backend/src/settlement/settlement.controller.ts`:
- Around line 23-26: The /verify endpoint currently trusts a client-supplied
user from req.body and passes it to verifySettlement (router.post("/verify") ->
verifySettlement), which allows impersonation; instead retrieve the
authenticated user/server-side identity from the request auth context (e.g.,
req.user, req.auth, or the decoded JWT in the middleware), validate that
identity and use that server-resolved user when calling verifySettlement, rather
than any user field from req.body; also validate/whitelist asset and amount from
the body before calling verifySettlement and return a 4xx error if the
authenticated user is missing or mismatched.
- Around line 11-20: The snooze and unsnooze endpoints accept userId from the
request body allowing any caller to modify another user’s state; change the
handlers for router.post("/snooze") and router.post("/unsnooze") to derive the
target user ID from the authenticated request (e.g., req.user.id or
req.auth.userId) instead of req.body.userId, or only allow a body userId when
the caller has an admin role (validate req.user.role), and still validate the
authenticated user’s permission; also validate the until value passed into
snoozeSettlement (ensure it’s a valid future date) and keep using
snoozeSettlement(userId, new Date(until)) and unsnoozeSettlement(userId) once
the userId source is secured.
In `@backend/src/settlement/settlement.repository.ts`:
- Around line 9-12: Replace the MongoDB-style `{ $lt: now }` with TypeORM
FindOperators: import and use LessThan(now) and IsNull() in the query where
clause so it becomes something like `where: [{ snoozedUntil: IsNull() }, {
snoozedUntil: LessThan(now) }]`; ensure the import of LessThan and IsNull from
'typeorm' and update the repository query (the `where` object handling
snoozedUntil in settlement.repository.ts) accordingly.
- Around line 16-22: The updateSnooze and clearSnooze functions currently ignore
TypeORM's UpdateResult so a missing user is silently ignored; call
userRepo.update(...) and inspect the returned UpdateResult. If result.affected
=== 0, throw a suitable not-found error (or return an error) so callers know the
user was not found; updateSnooze and clearSnooze should both perform this check
after the call to userRepo.update. Ensure you reference the
UpdateResult.affected property when implementing the check.
In `@backend/src/settlement/settlement.service.ts`:
- Around line 15-24: The current placeholder in settlement.service.ts uses a
single global sum (const total = participants.reduce(...)) and strict equality
to 0 to decide status, which is brittle for decimal balances and doesn't cover
per-participant inconsistencies; replace this with robust logic in the same
module/function: compute totals in a safe numeric domain (use integer cents or a
BigNumber library) and an EPS tolerance for decimal comparisons, verify each
participant's net balance is within EPS to mark them as settled, detect any
participants with conflicting signs to mark the suggestion as "partial", and if
any arithmetic mismatch remains mark "invalid"; update the code that pushes into
suggestions (the array mutated by this logic) to include per-participant
settlement flags/details and use function/variable names participants, balances,
total, and suggestions so the fix is easy to locate.
- Around line 37-38: The verifySettlement function is passing the internal
User.id (UUID) into verifyBalance which expects a Stellar account public key;
change verifySettlement(user: User, asset: string, amount: number) to accept a
stellarAccountId (or add a new parameter stellarAccountId: string) and call
verifyBalance(stellarAccountId, asset, amount) instead of
verifyBalance(user.id,...). Update callers to resolve the Stellar public key
from the authenticated request context or participant record before invoking
verifySettlement, and ensure the User entity remains unchanged (no assumption of
a stellar field inside User).
In `@backend/src/settlement/tests/settlement.service.spec.ts`:
- Around line 5-9: The test calls generateSuggestions() without arranging any
repository state or mocks, so it can return an empty array and cause a flaky
assertion; update the spec to explicitly set up the required data or mock the
repository methods used by generateSuggestions (e.g., spyOn/ mockReturnValue for
the participant/balance repository methods that generateSuggestions reads) so
the function returns a non-empty suggestions array with net-zero balances, then
assert suggestions.length > 0 before checking suggestions[0].status ===
"completed". Ensure you reference generateSuggestions and the repository methods
it depends on when adding the fixtures/mocks.
- Around line 11-24: Tests call snoozeSettlement(userId) and
unsnoozeSettlement(userId) using a hardcoded "test-user" but never create that
user, so the DB updates may affect zero rows and assertions become unreliable;
update each test (or a beforeEach) to create a real user fixture via
userRepo.save/insert with id "test-user" (and any required fields) before
calling snoozeSettlement/unsnoozeSettlement, and optionally cleanup after the
test, then ensure you assert that userRepo.findOneBy({ id: userId }) returns a
defined user before checking snoozedUntil; reference snoozeSettlement,
unsnoozeSettlement and userRepo.findOneBy to locate where to add the fixture
setup/teardown.
In `@backend/src/utils/stellarVerification.ts`:
- Around line 5-9: The verifyBalance function should handle
network/invalid-account errors and correctly detect native XLM balances: wrap
the call to server.loadAccount(accountId) in a try/catch and return false (or
handle/log) on failure instead of letting the exception bubble; when scanning
account.balances, match a balance by treating native XLM specially (check
b.asset_type === 'native' for asset === 'XLM') in addition to matching
b.asset_code === asset, then compare Number(b.balance) >= expected; update
verifyBalance to use these checks so server.loadAccount, account.balances,
asset_code and asset_type are handled correctly.
- Around line 1-3: The import at the top of stellarVerification.ts is
wrong—replace the module specifier "stellar-sdk" with the installed package
"@stellar/stellar-sdk" so the Server class resolves; update the import statement
that currently references Server and the existing const server = new Server(...)
to import Server from "@stellar/stellar-sdk" instead.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0da66237-dde0-4acd-b086-7e10ec88b193
📒 Files selected for processing (6)
backend/src/settlement/entities/user.entity.tsbackend/src/settlement/settlement.controller.tsbackend/src/settlement/settlement.repository.tsbackend/src/settlement/settlement.service.tsbackend/src/settlement/tests/settlement.service.spec.tsbackend/src/utils/stellarVerification.ts
| @Entity("users") | ||
| export class User { | ||
| @PrimaryGeneratedColumn("uuid") | ||
| id: string; | ||
|
|
||
| @Column("jsonb", { default: {} }) | ||
| balances: Record<string, number>; // asset → amount | ||
|
|
||
| @Column({ type: "timestamp", nullable: true }) | ||
| snoozedUntil: Date | null; | ||
| } |
There was a problem hiding this comment.
Avoid a second User entity mapped to users.
Lines 3–13 define a new User model under backend/src/settlement/entities, but the service/repository imports resolve to backend/src/entities/user.entity.ts. This splits schema assumptions and can break snooze/balance persistence in production paths.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/entities/user.entity.ts` around lines 3 - 13, You
added a second User entity class (class User) that maps to the same "users"
table, causing duplicate schema definitions; either remove this duplicate entity
and import the canonical User entity everywhere, or rename/repurpose this entity
and its `@Entity` name to avoid colliding with the existing User model. Locate
usages that import User from the settlement module and change them to import the
single canonical User export instead (or adjust repository/service imports to
the canonical model), and ensure only one entity is registered with the "users"
table so snoozedUntil and balances persist consistently.
| router.post("/snooze", async (req, res) => { | ||
| const { userId, until } = req.body; | ||
| await snoozeSettlement(userId, new Date(until)); | ||
| res.json({ success: true }); | ||
| }); | ||
|
|
||
| @Get("net-position") | ||
| async getNetPosition(@Req() req: any) { | ||
| return this.settlementService.calculateNetPosition(req.user.walletAddress); | ||
| } | ||
| router.post("/unsnooze", async (req, res) => { | ||
| const { userId } = req.body; | ||
| await unsnoozeSettlement(userId); | ||
| res.json({ success: true }); |
There was a problem hiding this comment.
Missing authorization allows snoozing/unsnoozing arbitrary users.
Lines 12 and 18 accept userId directly from body with no auth binding. Any caller can target another user’s snooze state.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/settlement.controller.ts` around lines 11 - 20, The
snooze and unsnooze endpoints accept userId from the request body allowing any
caller to modify another user’s state; change the handlers for
router.post("/snooze") and router.post("/unsnooze") to derive the target user ID
from the authenticated request (e.g., req.user.id or req.auth.userId) instead of
req.body.userId, or only allow a body userId when the caller has an admin role
(validate req.user.role), and still validate the authenticated user’s
permission; also validate the until value passed into snoozeSettlement (ensure
it’s a valid future date) and keep using snoozeSettlement(userId, new
Date(until)) and unsnoozeSettlement(userId) once the userId source is secured.
| router.post("/verify", async (req, res) => { | ||
| const { user, asset, amount } = req.body; | ||
| const verified = await verifySettlement(user, asset, amount); | ||
| res.json({ verified }); |
There was a problem hiding this comment.
/verify trusts a client-supplied user object (spoofing risk).
Lines 24–25 accept user from request body and pass it to verification. This lets clients impersonate identities/accounts. Resolve user server-side from auth context.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/settlement.controller.ts` around lines 23 - 26, The
/verify endpoint currently trusts a client-supplied user from req.body and
passes it to verifySettlement (router.post("/verify") -> verifySettlement),
which allows impersonation; instead retrieve the authenticated user/server-side
identity from the request auth context (e.g., req.user, req.auth, or the decoded
JWT in the middleware), validate that identity and use that server-resolved user
when calling verifySettlement, rather than any user field from req.body; also
validate/whitelist asset and amount from the body before calling
verifySettlement and return a 4xx error if the authenticated user is missing or
mismatched.
| where: [ | ||
| { snoozedUntil: null }, | ||
| { snoozedUntil: { $lt: now } } | ||
| ] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and read the relevant lines
if [ -f "backend/src/settlement/settlement.repository.ts" ]; then
echo "=== File exists, reading lines 1-30 ==="
head -30 "backend/src/settlement/settlement.repository.ts" | cat -n
else
echo "File not found at: backend/src/settlement/settlement.repository.ts"
# Try to find it
find . -name "settlement.repository.ts" -type f 2>/dev/null
fiRepository: OlufunbiIK/StellarSplit
Length of output: 875
🏁 Script executed:
# Check the TypeORM version in package.json or package-lock.json
echo "=== Checking TypeORM version ==="
if [ -f "package.json" ]; then
grep -A 1 -B 1 '"typeorm"' package.json
fi
if [ -f "package-lock.json" ]; then
echo "=== From package-lock.json ==="
grep -A 5 '"typeorm"' package-lock.json | head -20
fiRepository: OlufunbiIK/StellarSplit
Length of output: 541
🏁 Script executed:
# Search for the specific query pattern in the file to understand context
echo "=== Searching for snoozedUntil queries ==="
rg "snoozedUntil" --context 5 backend/src/settlement/ 2>/dev/null || rg "snoozedUntil" --context 5 . 2>/dev/null | head -60Repository: OlufunbiIK/StellarSplit
Length of output: 5047
🏁 Script executed:
# Check imports in settlement.service.ts to see the pattern
echo "=== Imports in settlement.service.ts ==="
head -20 backend/src/settlement/settlement.service.ts | cat -nRepository: OlufunbiIK/StellarSplit
Length of output: 1087
🏁 Script executed:
# Check if LessThan and IsNull are used anywhere
echo "=== Search for LessThan/IsNull usage ==="
rg "LessThan|IsNull" backend/src/ 2>/dev/null || echo "Not found in backend/src"Repository: OlufunbiIK/StellarSplit
Length of output: 5183
🏁 Script executed:
# Check for any MongoDB-style operators ($lt, $eq, $gt, etc.)
echo "=== Search for MongoDB-style operators ==="
rg '\$\w+:' backend/src/settlement/ 2>/dev/null || echo "No MongoDB operators found"Repository: OlufunbiIK/StellarSplit
Length of output: 194
Use TypeORM FindOperators, not MongoDB-style $lt.
Line 11 uses { $lt: now }, which is invalid MongoDB syntax. TypeORM 0.3 requires FindOperator functions like LessThan() and IsNull(). This will fail at runtime.
Proposed fix
+import { LessThan, IsNull } from "typeorm";
...
return userRepo.find({
where: [
- { snoozedUntil: null },
- { snoozedUntil: { $lt: now } }
+ { snoozedUntil: IsNull() },
+ { snoozedUntil: LessThan(now) }
]
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| where: [ | |
| { snoozedUntil: null }, | |
| { snoozedUntil: { $lt: now } } | |
| ] | |
| import { LessThan, IsNull } from "typeorm"; | |
| // ... other imports and code ... | |
| where: [ | |
| { snoozedUntil: IsNull() }, | |
| { snoozedUntil: LessThan(now) } | |
| ] |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/settlement.repository.ts` around lines 9 - 12, Replace
the MongoDB-style `{ $lt: now }` with TypeORM FindOperators: import and use
LessThan(now) and IsNull() in the query where clause so it becomes something
like `where: [{ snoozedUntil: IsNull() }, { snoozedUntil: LessThan(now) }]`;
ensure the import of LessThan and IsNull from 'typeorm' and update the
repository query (the `where` object handling snoozedUntil in
settlement.repository.ts) accordingly.
| export async function updateSnooze(userId: string, untilDate: Date) { | ||
| await userRepo.update(userId, { snoozedUntil: untilDate }); | ||
| } | ||
|
|
||
| export async function clearSnooze(userId: string) { | ||
| await userRepo.update(userId, { snoozedUntil: null }); | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, locate the user repository to understand the update() method
find . -type f -name "*.ts" | grep -i "user.*repo" | head -20Repository: OlufunbiIK/StellarSplit
Length of output: 49
🏁 Script executed:
# Also search for the settlement repository and related files
find . -type f -name "*.ts" -path "*/settlement/*"Repository: OlufunbiIK/StellarSplit
Length of output: 648
🏁 Script executed:
# Search for userRepo definition and update method
rg "userRepo\s*=" --type ts -A 3 -B 3 | head -50Repository: OlufunbiIK/StellarSplit
Length of output: 651
🏁 Script executed:
# Look for the update method in repository implementations
rg "\.update\(" --type ts -B 2 -A 5 | head -100Repository: OlufunbiIK/StellarSplit
Length of output: 7130
🏁 Script executed:
# Read the settlement.repository.ts file to see full context
cat -n backend/src/settlement/settlement.repository.tsRepository: OlufunbiIK/StellarSplit
Length of output: 835
🏁 Script executed:
# Search for all userRepo.update calls in the codebase
rg "userRepo\.update" --type ts -B 2 -A 5Repository: OlufunbiIK/StellarSplit
Length of output: 1304
🏁 Script executed:
# Search for TypeORM update patterns and error handling
rg "\.update\(" --type ts -B 1 -A 3 | grep -A 3 -B 1 "affected\|UpdateResult"Repository: OlufunbiIK/StellarSplit
Length of output: 49
🏁 Script executed:
# Search for calls to updateSnooze and clearSnooze to see if there's validation before
rg "updateSnooze|clearSnooze" --type ts -B 3 -A 1Repository: OlufunbiIK/StellarSplit
Length of output: 1610
🏁 Script executed:
# Check settlement.service.ts to see the full context of how updateSnooze is called
cat -n backend/src/settlement/settlement.service.ts | head -100Repository: OlufunbiIK/StellarSplit
Length of output: 4257
🏁 Script executed:
# Search for TypeORM UpdateResult or examples of checking affected
rg "affected|UpdateResult" --type tsRepository: OlufunbiIK/StellarSplit
Length of output: 4194
🏁 Script executed:
# Check if NotFoundException is used in settlement module
rg "NotFoundException" backend/src/settlement/ --type tsRepository: OlufunbiIK/StellarSplit
Length of output: 250
🏁 Script executed:
# Check settlement.controller.ts to see how snooze endpoints are used
cat -n backend/src/settlement/settlement.controller.tsRepository: OlufunbiIK/StellarSplit
Length of output: 2888
Handle "user not found" on snooze updates.
Lines 17 and 21 don't check the update result. TypeORM's update() returns an UpdateResult with an affected property, but these functions ignore it. If the user doesn't exist, the update silently succeeds with affected: 0, hiding failures and breaking snooze guarantees. The codebase already establishes this pattern elsewhere (e.g., soft-delete.service.ts, export.service.ts).
Proposed fix
export async function updateSnooze(userId: string, untilDate: Date) {
- await userRepo.update(userId, { snoozedUntil: untilDate });
+ const result = await userRepo.update(userId, { snoozedUntil: untilDate });
+ if (!result.affected) throw new NotFoundException("User not found");
}
export async function clearSnooze(userId: string) {
- await userRepo.update(userId, { snoozedUntil: null });
+ const result = await userRepo.update(userId, { snoozedUntil: null });
+ if (!result.affected) throw new NotFoundException("User not found");
}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/settlement.repository.ts` around lines 16 - 22, The
updateSnooze and clearSnooze functions currently ignore TypeORM's UpdateResult
so a missing user is silently ignored; call userRepo.update(...) and inspect the
returned UpdateResult. If result.affected === 0, throw a suitable not-found
error (or return an error) so callers know the user was not found; updateSnooze
and clearSnooze should both perform this check after the call to
userRepo.update. Ensure you reference the UpdateResult.affected property when
implementing the check.
| export async function verifySettlement(user: User, asset: string, amount: number): Promise<boolean> { | ||
| return verifyBalance(user.id, asset, amount); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find backend -name "settlement.service.ts" -type fRepository: OlufunbiIK/StellarSplit
Length of output: 111
🏁 Script executed:
cat -n backend/src/settlement/settlement.service.tsRepository: OlufunbiIK/StellarSplit
Length of output: 6764
🏁 Script executed:
find backend -name "user.entity.ts" -type fRepository: OlufunbiIK/StellarSplit
Length of output: 149
🏁 Script executed:
cat -n backend/src/entities/user.entity.tsRepository: OlufunbiIK/StellarSplit
Length of output: 1206
🏁 Script executed:
find backend -name "stellarVerification.ts" -o -name "stellarVerification.js"Repository: OlufunbiIK/StellarSplit
Length of output: 107
🏁 Script executed:
cat -n backend/src/utils/stellarVerification.tsRepository: OlufunbiIK/StellarSplit
Length of output: 534
🏁 Script executed:
rg -A 5 "stellarAccountId\|walletAddress\|stellar.*account" backend/src/entities/user.entity.tsRepository: OlufunbiIK/StellarSplit
Length of output: 49
🏁 Script executed:
rg "walletAddress|stellarAccountId|stellar.*id" backend/src/entities/ -A 2Repository: OlufunbiIK/StellarSplit
Length of output: 244
🏁 Script executed:
cat -n backend/src/entities/participant.entity.ts | head -50Repository: OlufunbiIK/StellarSplit
Length of output: 1423
🏁 Script executed:
rg "verifySettlement" backend/src/ -B 2 -A 2Repository: OlufunbiIK/StellarSplit
Length of output: 1250
Pass Stellar account ID, not internal user UUID, to verifyBalance.
Line 38 passes user.id to verifyBalance, but user.id is a UUID (defined as @PrimaryGeneratedColumn("uuid") in the User entity). The verifyBalance function calls server.loadAccount(accountId), which is a Stellar Horizon API requiring a Stellar account public key. This will fail at runtime with an invalid account format error.
The User entity has no Stellar account ID field. Consider accepting stellarAccountId as a function parameter and resolving it from the authenticated request context server-side.
Example fix
-export async function verifySettlement(user: User, asset: string, amount: number): Promise<boolean> {
- return verifyBalance(user.id, asset, amount);
+export async function verifySettlement(stellarAccountId: string, asset: string, amount: number): Promise<boolean> {
+ return verifyBalance(stellarAccountId, asset, amount);
}Then extract stellarAccountId from the authenticated user or participant record before calling this function.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export async function verifySettlement(user: User, asset: string, amount: number): Promise<boolean> { | |
| return verifyBalance(user.id, asset, amount); | |
| export async function verifySettlement(stellarAccountId: string, asset: string, amount: number): Promise<boolean> { | |
| return verifyBalance(stellarAccountId, asset, amount); | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/settlement.service.ts` around lines 37 - 38, The
verifySettlement function is passing the internal User.id (UUID) into
verifyBalance which expects a Stellar account public key; change
verifySettlement(user: User, asset: string, amount: number) to accept a
stellarAccountId (or add a new parameter stellarAccountId: string) and call
verifyBalance(stellarAccountId, asset, amount) instead of
verifyBalance(user.id,...). Update callers to resolve the Stellar public key
from the authenticated request context or participant record before invoking
verifySettlement, and ensure the User entity remains unchanged (no assumption of
a stellar field inside User).
| it("should generate completed suggestion when balances net to zero", async () => { | ||
| // mock participants with zero balances | ||
| const suggestions = await generateSuggestions(); | ||
| expect(suggestions[0].status).toBe("completed"); | ||
| }); |
There was a problem hiding this comment.
This test is not deterministic as written.
Line 6 says “mock participants,” but no mock/fixture is arranged. generateSuggestions() depends on repository state, and Line 8 can break on empty results.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/tests/settlement.service.spec.ts` around lines 5 - 9,
The test calls generateSuggestions() without arranging any repository state or
mocks, so it can return an empty array and cause a flaky assertion; update the
spec to explicitly set up the required data or mock the repository methods used
by generateSuggestions (e.g., spyOn/ mockReturnValue for the participant/balance
repository methods that generateSuggestions reads) so the function returns a
non-empty suggestions array with net-zero balances, then assert
suggestions.length > 0 before checking suggestions[0].status === "completed".
Ensure you reference generateSuggestions and the repository methods it depends
on when adding the fixtures/mocks.
| it("should persist snooze state", async () => { | ||
| const userId = "test-user"; | ||
| const until = new Date(Date.now() + 3600 * 1000); | ||
| await snoozeSettlement(userId, until); | ||
| const user = await userRepo.findOneBy({ id: userId }); | ||
| expect(user?.snoozedUntil).toEqual(until); | ||
| }); | ||
|
|
||
| it("should clear snooze state", async () => { | ||
| const userId = "test-user"; | ||
| await unsnoozeSettlement(userId); | ||
| const user = await userRepo.findOneBy({ id: userId }); | ||
| expect(user?.snoozedUntil).toBeNull(); | ||
| }); |
There was a problem hiding this comment.
Snooze tests need a real fixture user before asserting persistence.
Lines 12/20 use a hardcoded user ID without setup. update(...) may affect zero rows, making these checks unreliable (Line 16 may fail; Line 23 may pass trivially with undefined).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/settlement/tests/settlement.service.spec.ts` around lines 11 -
24, Tests call snoozeSettlement(userId) and unsnoozeSettlement(userId) using a
hardcoded "test-user" but never create that user, so the DB updates may affect
zero rows and assertions become unreliable; update each test (or a beforeEach)
to create a real user fixture via userRepo.save/insert with id "test-user" (and
any required fields) before calling snoozeSettlement/unsnoozeSettlement, and
optionally cleanup after the test, then ensure you assert that
userRepo.findOneBy({ id: userId }) returns a defined user before checking
snoozedUntil; reference snoozeSettlement, unsnoozeSettlement and
userRepo.findOneBy to locate where to add the fixture setup/teardown.
| import { Server } from "stellar-sdk"; | ||
|
|
||
| const server = new Server("https://horizon-testnet.stellar.org"); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -type f \( -name "package.json" -o -name "package-lock.json" -o -name "yarn.lock" \) | head -5Repository: OlufunbiIK/StellarSplit
Length of output: 190
🏁 Script executed:
rg "@stellar/stellar-sdk|stellar-sdk" -t json | grep -E "(stellar-sdk|@stellar)" | head -20Repository: OlufunbiIK/StellarSplit
Length of output: 448
🏁 Script executed:
cat backend/src/utils/stellarVerification.ts 2>/dev/null || echo "File may not exist or path may differ"Repository: OlufunbiIK/StellarSplit
Length of output: 471
🏁 Script executed:
fd -t f "stellarVerification" backend/Repository: OlufunbiIK/StellarSplit
Length of output: 107
🌐 Web query:
@stellar/stellar-sdk v14 Server import correct usage documentation
💡 Result:
The correct usage for importing and using the Server class from @stellar/stellar-sdk v14 (latest v14.6.1 as of 2026-03-04) is as follows: Installation: npm install --save @stellar/stellar-sdk Import (ES6 modules): import * as StellarSdk from '@stellar/stellar-sdk'; // or for tree-shaking: import { Server } from '@stellar/stellar-sdk'; CommonJS: const StellarSdk = require('@stellar/stellar-sdk'); Usage examples: For Horizon Server (REST API): const server = new StellarSdk.Server('https://horizon-testnet.stellar.org'); For Soroban RPC Server: const server = new StellarSdk.Server('https://soroban-testnet.stellar.org'); Example - Load account: const account = await server.getAccount('GBZC6Y2Y7Q3ZQ2Y4QZJ2XZ3Z5YXZ6Z7Z2Y4QZJ2XZ3Z5YXZ6Z7Z2Y4'); console.log('sequence:', account.sequence); There are two Server classes: one for Horizon (lib/horizon/server.js) and one for Soroban RPC (lib/rpc/server.js), both exported from the main package and accessible via StellarSdk.Server. Use the appropriate server URL to instantiate the correct type. Official documentation: https://stellar.github.io/js-stellar-sdk/
Citations:
- 1: https://stellar.github.io/js-stellar-sdk/module-rpc.Server.html
- 2: https://stellar.github.io/js-stellar-sdk/Server.html
- 3: https://github.com/stellar/js-stellar-sdk
- 4: https://registry.npmjs.org/%40stellar%2Fstellar-sdk
- 5: https://github.com/stellar/js-stellar-sdk/blob/master/CHANGELOG.md
- 6: https://stellar.github.io/js-stellar-sdk/libdocs_server.js.html
- 7: https://www.stellar.org/developers/js-stellar-sdk/reference/
- 8: https://stellar.github.io/js-stellar-sdk/lib_rpc_server.js.html
🏁 Script executed:
cat backend/package.json | grep -A 5 -B 5 "stellar-sdk"Repository: OlufunbiIK/StellarSplit
Length of output: 455
🏁 Script executed:
# Check if there's a type definition or barrel export in node_modules or tsconfig
find backend -type f \( -name "tsconfig.json" -o -name "*.d.ts" \) 2>/dev/null | head -10Repository: OlufunbiIK/StellarSplit
Length of output: 204
🏁 Script executed:
# Look for any other imports of Server or Horizon in the codebase to see what pattern is actually used
rg "import.*Server|import.*Horizon" backend/ --type ts --type tsxRepository: OlufunbiIK/StellarSplit
Length of output: 94
🏁 Script executed:
rg "import.*Server" backend/ --type tsRepository: OlufunbiIK/StellarSplit
Length of output: 786
🏁 Script executed:
rg "Server|Horizon" backend/src/utils/stellarVerification.tsRepository: OlufunbiIK/StellarSplit
Length of output: 170
Fix incorrect Stellar SDK package import.
Line 1 imports from "stellar-sdk" which does not exist. The installed package is @stellar/stellar-sdk v14.4.3. Change the import to use the correct package name:
Proposed fix
-import { Server } from "stellar-sdk";
+import { Server } from "@stellar/stellar-sdk";
const server = new Server("https://horizon-testnet.stellar.org");📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import { Server } from "stellar-sdk"; | |
| const server = new Server("https://horizon-testnet.stellar.org"); | |
| import { Server } from "@stellar/stellar-sdk"; | |
| const server = new Server("https://horizon-testnet.stellar.org"); |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/utils/stellarVerification.ts` around lines 1 - 3, The import at
the top of stellarVerification.ts is wrong—replace the module specifier
"stellar-sdk" with the installed package "@stellar/stellar-sdk" so the Server
class resolves; update the import statement that currently references Server and
the existing const server = new Server(...) to import Server from
"@stellar/stellar-sdk" instead.
| export async function verifyBalance(accountId: string, asset: string, expected: number): Promise<boolean> { | ||
| const account = await server.loadAccount(accountId); | ||
| const balance = account.balances.find(b => b.asset_code === asset); | ||
| return balance ? Number(balance.balance) >= expected : false; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n backend/src/utils/stellarVerification.tsRepository: OlufunbiIK/StellarSplit
Length of output: 534
🏁 Script executed:
# Search for imports and server definition
rg -n "import|server" backend/src/utils/stellarVerification.ts -A 2 -B 2Repository: OlufunbiIK/StellarSplit
Length of output: 485
🏁 Script executed:
# Check if there are any tests or related files that use this function
fd -e test -e spec | xargs rg -l "verifyBalance" 2>/dev/null || echo "No test files found"Repository: OlufunbiIK/StellarSplit
Length of output: 152
🏁 Script executed:
# Search for error handling patterns around this function in the codebase
rg -n "loadAccount|balances\.find" backend/src --type ts -A 2 -B 2 | head -50Repository: OlufunbiIK/StellarSplit
Length of output: 1050
🏁 Script executed:
# Check the broader context of how this function is used
rg -n "verifyBalance" backend/src --type ts -B 3 -A 3Repository: OlufunbiIK/StellarSplit
Length of output: 1750
🏁 Script executed:
# Search for any test files or documentation mentioning native assets or balances
rg -n "native|asset_code|asset_type" backend/src --type ts -B 2 -A 2 | head -60Repository: OlufunbiIK/StellarSplit
Length of output: 5761
🌐 Web query:
Stellar SDK native asset balances asset_code structure
💡 Result:
In the Stellar SDK, native asset balances are retrieved via the Horizon API by querying an account endpoint (e.g., server.loadAccount(accountId)), which returns an AccountResponse containing a 'balances' array. Each balance object in the array has this structure: For the native asset (XLM): - balance: string (e.g., "9997.6802725") - asset_type: "native" - No asset_code or asset_issuer For issued (non-native) assets: - balance: string (e.g., "126.8107491") - limit: string (e.g., "5000.0000000") - trust limit - asset_type: "credit_alphanum4" or "credit_alphanum12" - asset_code: string (e.g., "BAR", "FOO") - up to 4 or 12 alphanumeric chars - asset_issuer: string (account ID, e.g., "GBAUUA74H4XOQYRSOW2RZUA4QL5PB37U3JS5NE3RTB2ELJVMIF5RLMAG") Additional fields may include buying_liabilities, selling_liabilities, last_modified_ledger. The Stellar SDK Asset class constructor is new Asset(code: string, issuer: string), with Asset.native for native. Asset codes are 1-12 alphanumeric chars for issued assets; native has no code.
Citations:
- 1: https://docs.stellarcn.org/horizon/reference/endpoints/accounts-single.html
- 2: https://github.com/stellar/go/blob/d121c23554421abeb33273ef74114a30c41b409e/services/horizon/internal/docs/reference/resources/account.md
- 3: https://stellar.github.io/js-stellar-sdk/Asset.html
🏁 Script executed:
# Check if there are any balance-related tests or examples
fd -name "*.test.ts" -o -name "*.spec.ts" | xargs rg -l "balance" 2>/dev/null || echo "No balance tests found"Repository: OlufunbiIK/StellarSplit
Length of output: 1747
🏁 Script executed:
# Look at the settlement.service to understand the context better
cat -n backend/src/settlement/settlement.service.ts | head -50Repository: OlufunbiIK/StellarSplit
Length of output: 2364
Add error handling and support native XLM balances.
Line 6 (server.loadAccount()) lacks error handling for network failures and invalid accounts. Additionally, line 7 only checks asset_code, which doesn't exist on native XLM balances (these have asset_type: "native" instead). This causes the function to return false when verifying XLM, rather than actually checking the balance. The codebase correctly handles this distinction elsewhere (see stellar.service.ts and debt-simplification.service.ts).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/src/utils/stellarVerification.ts` around lines 5 - 9, The
verifyBalance function should handle network/invalid-account errors and
correctly detect native XLM balances: wrap the call to
server.loadAccount(accountId) in a try/catch and return false (or handle/log) on
failure instead of letting the exception bubble; when scanning account.balances,
match a balance by treating native XLM specially (check b.asset_type ===
'native' for asset === 'XLM') in addition to matching b.asset_code === asset,
then compare Number(b.balance) >= expected; update verifyBalance to use these
checks so server.loadAccount, account.balances, asset_code and asset_type are
handled correctly.
2 participants
📝 Description
Overview
This PR fixes and finalizes the Settlement Suggestions and Snooze Logic.
It removes placeholder assumptions, ensures deterministic settlement flows, and implements snooze persistence with full verification.
Key Features
Userand settlement service✅ Acceptance Criteria
📂 File Changes
backend/src/settlement/settlement.service.ts— core logic cleanupbackend/src/settlement/settlement.controller.ts— endpoints for suggestions, snooze, verifybackend/src/settlement/settlement.repository.ts— persistence methodsbackend/src/entities/user.entity.ts— snooze field addedbackend/src/settlement/__tests__/settlement.service.spec.ts— unit testsCloses #290
Summary by CodeRabbit
New Features
Tests