Conversation
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
kewitz
force-pushed
the
refact/account-detail-overview
branch
from
96fab66 to
6e63ea9
Compare
Comment on lines
+111
to
+112
| ${ifStr(replacements.totalExpendedExpression, () => `AND chts."debitTotal" ${replacements.totalExpendedExpression}`)} | ||
| ${ifStr(replacements.totalContributedExpression, () => `AND chts."creditTotal" ${replacements.totalContributedExpression}`)} |
There was a problem hiding this comment.
Bug: The LEFT JOIN on CommunityHostTransactionSummary can result in NULL for debitTotal. The filter on this column then incorrectly excludes accounts with no transaction history.
Severity: MEDIUM
Suggested Fix
Modify the WHERE clause to explicitly include rows where the total is NULL. Similar to the pattern in Host.ts, the filter should be changed to something like (chts."debitTotal" <= X OR chts."debitTotal" IS NULL) to correctly include accounts with no transactions.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: server/graphql/v2/query/collection/CommunityQuery.ts#L111-L112
Potential issue: The query in `CommunityQuery.ts` uses a `LEFT JOIN` to
`CommunityHostTransactionSummary`. When filtering on transaction totals (e.g.,
`totalExpended <= X`), accounts with no transaction history will have `NULL` for the
`debitTotal` column. In PostgreSQL, `NULL <= X` evaluates to false, causing these
accounts to be incorrectly excluded from the results. This is a functional regression,
as the previous implementation used `COALESCE` to handle this case correctly. A similar
pattern for handling `NULL`s already exists in `Host.ts` but was not applied here.
gustavlrsn
reviewed
Mar 19, 2026
Member
gustavlrsn
left a comment
gustavlrsn
left a comment
There was a problem hiding this comment.
Nice work. I like the simplification and clarity of the concepts, added some smaller comments
Comment on lines
+1721
to
+1724
| // direction, | ||
| ); | ||
| } else if (args?.orderBy?.field) { | ||
| nodeQuery = nodeQuery.orderBy(args.orderBy.field, direction); | ||
| nodeQuery = nodeQuery.orderBy(args.orderBy.field); // direction); |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
kewitz
force-pushed
the
refact/account-detail-overview
branch
from
274db2f to
4ba8a14
Compare
Comment on lines
+1343
to
+1352
| const accountConditions = {}; | ||
| if (!args.direction || args.direction === 'SUBMITTED') { | ||
| accountConditions['fromAccount'] = { legacyId: collective.id }; | ||
| } | ||
| if (!args.direction || args.direction === 'RECEIVED') { | ||
| accountConditions['account'] = { legacyId: collective.id }; | ||
| } | ||
|
|
||
| args = omit({ ...args, ...accountConditions }, ['direction']); | ||
| return ExpensesCollectionQueryResolver(undefined, args, req); |
There was a problem hiding this comment.
Bug: When the direction argument is omitted in Account.expenses, both fromAccount and account filters are incorrectly applied, causing the query to return almost no results.
Severity: CRITICAL
Suggested Fix
Modify the conditional logic to ensure that when direction is not provided, only the account filter is set, restoring the previous default behavior. This can be achieved by using an else if for the second condition to prevent both blocks from executing when direction is undefined.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: server/graphql/v2/interface/Account.ts#L1343-L1352
Potential issue: In the `Account.expenses` resolver, when the `direction` argument is
not provided, the logic incorrectly sets both the `fromAccount` and `account` filters to
the same collective ID. This generates an SQL query with a `WHERE` clause that requires
an account to be both the payer (`FromCollectiveId`) and the payee (`CollectiveId`) for
the same expense. This condition is almost never met, causing the query to return an
empty result set and breaking the expected default behavior of listing expenses received
by the account.
gustavlrsn
approved these changes
Mar 31, 2026
- CommunityTransactionSummary is now granular to CollectiveId and kind - CommunityHostYearlyTransactionSummary that summarizes both kind and CollectiveId, providing a year summary between FromCollectiveId and HostCollectiveId - CommunityHostTransactionSummary is similar, but summarizes across years and kind, replacing the previous Aggregation that was only being used to fetch the total summary either way.
kewitz
force-pushed
the
refact/account-detail-overview
branch
from
4ba8a14 to
e4e4baa
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on #11586