Skip to content

Copilot/refactor serverless azure function#17970

Closed
ASISaga wants to merge 8 commits intoopenclaw:mainfrom
ASISaga:copilot/refactor-serverless-azure-function
Closed

Copilot/refactor serverless azure function#17970
ASISaga wants to merge 8 commits intoopenclaw:mainfrom
ASISaga:copilot/refactor-serverless-azure-function

Conversation

@ASISaga
Copy link
Copy Markdown

@ASISaga ASISaga commented Feb 16, 2026

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem:
  • Why it matters:
  • What changed:
  • What did NOT change (scope boundary):

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Security Impact (required)

  • New permissions/capabilities? (Yes/No)
  • Secrets/tokens handling changed? (Yes/No)
  • New/changed network calls? (Yes/No)
  • Command/tool execution surface changed? (Yes/No)
  • Data access scope changed? (Yes/No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS:
  • Runtime/container:
  • Model/provider:
  • Integration/channel (if any):
  • Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
  • Edge cases checked:
  • What you did not verify:

Compatibility / Migration

  • Backward compatible? (Yes/No)
  • Config/env changes? (Yes/No)
  • Migration needed? (Yes/No)
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
  • Files/config to restore:
  • Known bad symptoms reviewers should watch for:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk:
    • Mitigation:

Greptile Summary

This PR adds a complete Azure Functions serverless deployment option for OpenClaw, including a Telegram webhook handler (azure-function/), an Azure Table Storage memory provider (src/memory/memory-provider-azure.ts), an Azure Blob Storage session store, Bicep infrastructure-as-code, comprehensive docs, and tests.

  • Webhook handler (azure-function/src/functions/webhook.ts): Implements a POST-triggered Azure Function that validates Telegram webhook headers and processes updates via grammy. Contains two issues: (1) authentication validation runs after body parsing (should be before to reject unauthenticated requests early), and (2) dead health-check code inside the POST handler that's unreachable because /healthz has its own route registration.
  • Memory provider (src/memory/memory-provider-azure.ts): Implements MemorySearchManager using Azure Table Storage with keyword-based search, chunk/file/meta CRUD, and embedding cache. Previously flagged OData filter injection concerns remain. The provider is not yet wired into the search-manager factory.
  • Session store (azure-function/src/storage/session-store-azure.ts): Clean Blob Storage session persistence implementation with proper 404 handling and idempotent container creation.
  • Infrastructure (infra/main.bicep): Well-structured Bicep template provisioning Storage, Key Vault (with RBAC), Function App, and App Insights with appropriate security defaults.
  • Tests: Comprehensive unit tests for the memory provider with proper Azure SDK mocking.
  • Docs and README updates: Adds Azure deployment guide and cross-references from existing docs.

Confidence Score: 3/5

  • PR is mostly additive with no changes to existing logic, but the webhook has an auth ordering bug that should be fixed before merging.
  • Score of 3 reflects that this is a large, additive PR with well-structured code and good test coverage, but the webhook authentication ordering issue (body parsed before validation) is a real logic bug that should be corrected. The dead health-check code is minor but indicates incomplete cleanup. The previously-flagged OData injection concerns in the memory provider also remain unaddressed.
  • Pay close attention to azure-function/src/functions/webhook.ts (auth ordering bug and dead code) and src/memory/memory-provider-azure.ts (previously flagged OData filter injection concerns).

Last reviewed commit: a35d2a5

Copilot AI and others added 8 commits February 16, 2026 07:06
- Created docs/install/azure.md with full Azure Functions deployment guide
- Updated docs/vps.md to include Azure as a serverless deployment option
- Updated docs/platforms/index.md to reference Azure deployment
- Updated docs/docs.json navigation to include Azure in hosting section
- Updated README.md with Cloud & VPS Deployment section highlighting Azure

Co-authored-by: ASISaga <[email protected]>
…-deployment

docs: Add Azure Functions deployment documentation
@openclaw-barnacle openclaw-barnacle bot added docs Improvements or additions to documentation gateway Gateway runtime size: XL labels Feb 16, 2026
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

19 files reviewed, 3 comments

Edit Code Review Agent Settings | Greptile

const results: MemorySearchResult[] = [];

const iter = this.chunksClient.listEntities<ChunkEntity>({
queryOptions: { filter: `PartitionKey eq '${this.agentId}'` },
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

SQL injection vulnerability via string interpolation in filter query.

agentId should be sanitized or parameterized.

Suggested change
queryOptions: { filter: `PartitionKey eq '${this.agentId}'` },
queryOptions: { filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}'` },
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/memory/memory-provider-azure.ts
Line: 156:156

Comment:
SQL injection vulnerability via string interpolation in filter query.

`agentId` should be sanitized or parameterized.

```suggestion
      queryOptions: { filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}'` },
```

How can I resolve this? If you propose a fix, please make it concise.


const iter = this.chunksClient.listEntities<ChunkEntity>({
queryOptions: {
filter: `PartitionKey eq '${this.agentId}' and path eq '${params.relPath}'`,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

SQL injection vulnerability via string interpolation in filter query.

Both agentId and params.relPath should be sanitized.

Suggested change
filter: `PartitionKey eq '${this.agentId}' and path eq '${params.relPath}'`,
filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}' and path eq '${params.relPath.replace(/'/g, "''")}'`,
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/memory/memory-provider-azure.ts
Line: 189:189

Comment:
SQL injection vulnerability via string interpolation in filter query.

Both `agentId` and `params.relPath` should be sanitized.

```suggestion
        filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}' and path eq '${params.relPath.replace(/'/g, "''")}'`,
```

How can I resolve this? If you propose a fix, please make it concise.

async deleteChunksByPath(path: string, source: MemorySource): Promise<void> {
const iter = this.chunksClient.listEntities<ChunkEntity>({
queryOptions: {
filter: `PartitionKey eq '${this.agentId}' and path eq '${path}' and source eq '${source}'`,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

SQL injection vulnerability via string interpolation in filter query.

All three variables (agentId, path, source) should be sanitized.

Suggested change
filter: `PartitionKey eq '${this.agentId}' and path eq '${path}' and source eq '${source}'`,
filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}' and path eq '${path.replace(/'/g, "''")}' and source eq '${source.replace(/'/g, "''")}'`,
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/memory/memory-provider-azure.ts
Line: 360:360

Comment:
SQL injection vulnerability via string interpolation in filter query.

All three variables (`agentId`, `path`, `source`) should be sanitized.

```suggestion
        filter: `PartitionKey eq '${this.agentId.replace(/'/g, "''")}' and path eq '${path.replace(/'/g, "''")}' and source eq '${source.replace(/'/g, "''")}'`,
```

How can I resolve this? If you propose a fix, please make it concise.

@steipete steipete closed this Feb 16, 2026
@steipete steipete reopened this Feb 17, 2026
Copy link
Copy Markdown
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

19 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +98 to +101
// Health-check endpoint
if (request.url.endsWith("/healthz")) {
return { status: 200, body: "ok" };
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Dead code — unreachable health check

This health-check branch is unreachable. The telegramWebhook handler is registered on route telegram-webhook (POST only), so a request to /healthz is never routed here — it goes to the dedicated healthz handler registered at line 143. This block should be removed to avoid confusion.

Suggested change
// Health-check endpoint
if (request.url.endsWith("/healthz")) {
return { status: 200, body: "ok" };
}
Prompt To Fix With AI
This is a comment left during a code review.
Path: azure-function/src/functions/webhook.ts
Line: 98:101

Comment:
**Dead code — unreachable health check**

This health-check branch is unreachable. The `telegramWebhook` handler is registered on route `telegram-webhook` (POST only), so a request to `/healthz` is never routed here — it goes to the dedicated `healthz` handler registered at line 143. This block should be removed to avoid confusion.

```suggestion
```

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +106 to +119
try {
// grammy's webhookCallback returns a handler for the Node http module.
// In Azure Functions v4 we need to adapt the request/response ourselves.
const body = await request.text();
const update = JSON.parse(body);

// Validate secret token header when configured.
if (secret) {
const headerSecret = request.headers.get("x-telegram-bot-api-secret-token") ?? "";
if (headerSecret !== secret) {
context.warn("Telegram webhook secret mismatch");
return { status: 401, body: "Unauthorized" };
}
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Webhook auth runs after body parsing

The request body is read and JSON-parsed (lines 109-110) before the webhook validation header is checked (lines 113-118). This means unauthenticated requests still trigger body reading and JSON parsing, wasting compute and exposing the parsing surface to untrusted input.

The existing webhook handler in src/telegram/webhook.ts validates authentication (via grammy's webhookCallback) before processing the body.

Move the header validation block (lines 113-118) to run before request.text() and JSON.parse(body) so unauthenticated requests are rejected early without reading the body.

Prompt To Fix With AI
This is a comment left during a code review.
Path: azure-function/src/functions/webhook.ts
Line: 106:119

Comment:
**Webhook auth runs after body parsing**

The request body is read and JSON-parsed (lines 109-110) *before* the webhook validation header is checked (lines 113-118). This means unauthenticated requests still trigger body reading and JSON parsing, wasting compute and exposing the parsing surface to untrusted input.

The existing webhook handler in `src/telegram/webhook.ts` validates authentication (via grammy's `webhookCallback`) before processing the body.

Move the header validation block (lines 113-118) to run before `request.text()` and `JSON.parse(body)` so unauthenticated requests are rejected early without reading the body.

How can I resolve this? If you propose a fix, please make it concise.

@openclaw-barnacle
Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle bot added stale Marked as stale due to inactivity and removed stale Marked as stale due to inactivity labels Feb 22, 2026
@openclaw-barnacle
Copy link
Copy Markdown

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

@openclaw-barnacle openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 15, 2026
@openclaw-barnacle
Copy link
Copy Markdown

Closing due to inactivity.
If you believe this PR should be revived, post in #pr-thunderdome-dangerzone on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

BradGroux added a commit to BradGroux/openclaw that referenced this pull request Mar 19, 2026
Resolved:
- openclaw#25790 (Teams issue, CLOSED)
- openclaw#47860 (Teams PR, CLOSED)
- openclaw#48116 (Azure issue, CLOSED)
- openclaw#48899 (Azure issue, CLOSED)
- openclaw#47898 (Azure PR, MERGED)
- openclaw#17970 (Azure PR, CLOSED)
- openclaw#21678 (Windows issue, CLOSED)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs Improvements or additions to documentation gateway Gateway runtime size: XL stale Marked as stale due to inactivity

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants