Skip to content

remove try catch#1310

Merged
iceljc merged 1 commit intoSciSharp:masterfrom
iceljc:master
Mar 17, 2026
Merged

remove try catch#1310
iceljc merged 1 commit intoSciSharp:masterfrom
iceljc:master

Conversation

@iceljc
Copy link
Collaborator

@iceljc iceljc commented Mar 17, 2026

No description provided.

@qodo-code-review
Copy link
Contributor

Review Summary by Qodo

Remove exception handling wrappers and propagate errors

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Remove try-catch wrapper from GraphKnowledgeService.ExecuteQueryAsync
• Propagate exceptions instead of catching and logging in MembaseGraphDb
• Simplify error handling by letting exceptions bubble up naturally
Diagram
flowchart LR
  A["GraphKnowledgeService.ExecuteQueryAsync"] -->|removed try-catch| B["Direct execution"]
  C["MembaseGraphDb.ExecuteQueryAsync"] -->|changed catch behavior| D["throw instead of return empty"]
  B --> E["Exceptions propagate up"]
  D --> E
Loading

Grey Divider

File Changes

1. src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs ✨ Enhancement +3/-11

Remove try-catch wrapper from ExecuteQueryAsync

• Removed try-catch block wrapping query execution
• Removed error logging in catch handler
• Removed empty GraphQueryResult fallback return
• Simplified method to direct execution and return

src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs


2. src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs ✨ Enhancement +1/-1

Change catch handler to throw exceptions

• Changed catch block to throw exception instead of returning empty result
• Removed graceful error handling fallback
• Allows exceptions to propagate to caller

src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Contributor

qodo-code-review bot commented Mar 17, 2026

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (2) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Removed query error fallback 📘 Rule violation ⛯ Reliability
Description
ExecuteQueryAsync no longer catches provider failures, so exceptions can bubble to callers with no
safe fallback result. This violates the requirement to return a safe fallback with clear logging at
provider boundaries.
Code

src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[R23-25]

+        var db = GetGraphDb(options?.Provider);
+        var result = await db.ExecuteQueryAsync(query, options);
+        return result;
Evidence
Compliance ID 2 requires boundary-facing/provider code to return a safe fallback and emit clear logs
on invalid/missing data or boundary failures; the PR removed the prior catch+log+fallback behavior
and now directly awaits the provider call and returns its result, allowing exceptions to escape.

src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[23-25]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GraphKnowledgeService.ExecuteQueryAsync` removed its try/catch and now lets provider/storage errors escape without returning a safe fallback or logging, violating the boundary guard/fallback requirement.

## Issue Context
This method is a provider/storage boundary (calls `GetGraphDb(...).ExecuteQueryAsync(...)`). The previous implementation returned a safe fallback `GraphQueryResult` and logged an error; the PR removed that behavior.

## Fix Focus Areas
- src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[23-25]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Rethrow breaks safe fallback 📘 Rule violation ⛯ Reliability
Description
The graph DB implementation now rethrows exceptions instead of returning a safe fallback result,
increasing the likelihood of runtime failures propagating across the provider boundary. This
violates the requirement for safe fallback behavior with clear logging at provider/storage
boundaries.
Code

src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[58]

+            throw;
Evidence
Compliance ID 2 requires boundary-facing/provider code to return safe fallback values (or null) with
clear logging instead of allowing exceptions to propagate; the PR changed the catch block from
returning an empty result to rethrowing the exception.

src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[58-58]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`MembaseGraphDb.ExecuteQueryAsync` now rethrows exceptions from the provider boundary instead of returning a safe fallback result.

## Issue Context
The catch block already logs the error; rethrowing defeats the safe fallback requirement and can cause upstream failures.

## Fix Focus Areas
- src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[58-58]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Null graph db dereference 🐞 Bug ⛯ Reliability
Description
GraphKnowledgeService.ExecuteQueryAsync can dereference a null IGraphDb when GetGraphDb returns null
(no registered provider match), causing a NullReferenceException that now propagates to callers.
This will break /knowledge/graph/search and any other callers because there is no controller- or
middleware-level exception handling in production.
Code

src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[R23-25]

+        var db = GetGraphDb(options?.Provider);
+        var result = await db.ExecuteQueryAsync(query, options);
+        return result;
Evidence
GetGraphDb uses FirstOrDefault and returns the result without null checking; ExecuteQueryAsync
immediately calls db.ExecuteQueryAsync. KnowledgeBaseController calls ExecuteQueryAsync without
try/catch, and the OpenAPI pipeline does not register a production exception handler, so this
becomes an unhandled exception and a 500 response.

src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[21-35]
src/Infrastructure/BotSharp.OpenAPI/Controllers/KnowledgeBase/KnowledgeBaseController.cs[208-224]
src/Infrastructure/BotSharp.OpenAPI/BotSharpOpenApiExtensions.cs[231-262]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GraphKnowledgeService.ExecuteQueryAsync` calls `db.ExecuteQueryAsync(...)` without verifying that `GetGraphDb(...)` actually found a provider, which can produce a `NullReferenceException`.

### Issue Context
`GetGraphDb` uses `FirstOrDefault` and can return null when configuration requests an unregistered provider.

### Fix Focus Areas
- src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[21-35]
- src/Infrastructure/BotSharp.OpenAPI/Controllers/KnowledgeBase/KnowledgeBaseController.cs[208-224]
- src/Infrastructure/BotSharp.OpenAPI/BotSharpOpenApiExtensions.cs[231-262]

### Implementation notes
- Add a null check after `GetGraphDb(...)`.
- Prefer preserving previous behavior (return empty `GraphQueryResult` and log) unless the API contract is explicitly changing; if changing to “throw”, add controller-level handling or a global exception handler middleware to return a controlled error response.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Exception message leaked to client 🐞 Bug ⛨ Security
Description
Because MembaseGraphDb now rethrows, MembaseController will return ex.Message to clients for query
execution errors, exposing internal exception details in the HTTP response body. This is a direct
consequence of the new throwing behavior combined with the controller’s error response structure.
Code

src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[58]

+            throw;
Evidence
MembaseGraphDb now throws on execution errors; MembaseController catches Exception and returns a 500
including error = ex.Message, which will now be populated for query failures.

src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[54-59]
src/Plugins/BotSharp.Plugin.Membase/Controllers/MembaseController.cs[54-59]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The Membase API endpoint returns `ex.Message` in the response body, which can leak internal details when `MembaseGraphDb` throws.

### Issue Context
`MembaseGraphDb` now rethrows on execution errors, so the controller’s exception path will be used for query failures.

### Fix Focus Areas
- src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[54-59]
- src/Plugins/BotSharp.Plugin.Membase/Controllers/MembaseController.cs[54-59]

### Implementation notes
- Replace `error = ex.Message` with a generic message (or omit the field).
- Ensure the full exception details remain in server logs for debugging.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

@iceljc iceljc merged commit 1b488b7 into SciSharp:master Mar 17, 2026
4 checks passed
Comment on lines +23 to +25
var db = GetGraphDb(options?.Provider);
var result = await db.ExecuteQueryAsync(query, options);
return result;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Removed query error fallback 📘 Rule violation ⛯ Reliability

ExecuteQueryAsync no longer catches provider failures, so exceptions can bubble to callers with no
safe fallback result. This violates the requirement to return a safe fallback with clear logging at
provider boundaries.
Agent Prompt
## Issue description
`GraphKnowledgeService.ExecuteQueryAsync` removed its try/catch and now lets provider/storage errors escape without returning a safe fallback or logging, violating the boundary guard/fallback requirement.

## Issue Context
This method is a provider/storage boundary (calls `GetGraphDb(...).ExecuteQueryAsync(...)`). The previous implementation returned a safe fallback `GraphQueryResult` and logged an error; the PR removed that behavior.

## Fix Focus Areas
- src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[23-25]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

var argLogs = args.Select(x => (new KeyValue(x.Key, x.Value.ConvertToString(BotSharpOptions.defaultJsonOptions))).ToString());
_logger.LogError(ex, $"Error when executing query in {Provider} graph db. (Query: {query}), (Argments: \r\n{string.Join("\r\n", argLogs)})");
return new();
throw;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Rethrow breaks safe fallback 📘 Rule violation ⛯ Reliability

The graph DB implementation now rethrows exceptions instead of returning a safe fallback result,
increasing the likelihood of runtime failures propagating across the provider boundary. This
violates the requirement for safe fallback behavior with clear logging at provider/storage
boundaries.
Agent Prompt
## Issue description
`MembaseGraphDb.ExecuteQueryAsync` now rethrows exceptions from the provider boundary instead of returning a safe fallback result.

## Issue Context
The catch block already logs the error; rethrowing defeats the safe fallback requirement and can cause upstream failures.

## Fix Focus Areas
- src/Plugins/BotSharp.Plugin.Membase/GraphDb/MembaseGraphDb.cs[58-58]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +23 to +25
var db = GetGraphDb(options?.Provider);
var result = await db.ExecuteQueryAsync(query, options);
return result;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

3. Null graph db dereference 🐞 Bug ⛯ Reliability

GraphKnowledgeService.ExecuteQueryAsync can dereference a null IGraphDb when GetGraphDb returns null
(no registered provider match), causing a NullReferenceException that now propagates to callers.
This will break /knowledge/graph/search and any other callers because there is no controller- or
middleware-level exception handling in production.
Agent Prompt
### Issue description
`GraphKnowledgeService.ExecuteQueryAsync` calls `db.ExecuteQueryAsync(...)` without verifying that `GetGraphDb(...)` actually found a provider, which can produce a `NullReferenceException`.

### Issue Context
`GetGraphDb` uses `FirstOrDefault` and can return null when configuration requests an unregistered provider.

### Fix Focus Areas
- src/Plugins/BotSharp.Plugin.KnowledgeBase/Graph/GraphKnowledgeService.cs[21-35]
- src/Infrastructure/BotSharp.OpenAPI/Controllers/KnowledgeBase/KnowledgeBaseController.cs[208-224]
- src/Infrastructure/BotSharp.OpenAPI/BotSharpOpenApiExtensions.cs[231-262]

### Implementation notes
- Add a null check after `GetGraphDb(...)`.
- Prefer preserving previous behavior (return empty `GraphQueryResult` and log) unless the API contract is explicitly changing; if changing to “throw”, add controller-level handling or a global exception handler middleware to return a controlled error response.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant