Ensure new headers are persisted/observable where intended

If you expect x-appwrite-execution-id and x-appwrite-client-ip to appear under the execution.requestHeaders for observability/debugging, confirm they are included in FUNCTION_ALLOWLIST_HEADERS_REQUEST; otherwise they’ll be filtered out.

Run this to verify and adjust if needed:

🏁 Script executed:

#!/bin/bash
# Check where FUNCTION_ALLOWLIST_HEADERS_REQUEST/RESPONSE are defined and whether they include the new headers.
rg -nP -C3 'FUNCTION_ALLOWLIST_HEADERS_(REQUEST|RESPONSE)'
echo
echo "Checking for the new headers in allowlists:"
rg -nP -C2 'x-appwrite-(execution-id|client-ip)'

Length of output: 10238

Confirm allowlists include the new headers

If you want x-appwrite-execution-id and x-appwrite-client-ip visible in execution.requestHeaders, ensure they’re in FUNCTION_ALLOWLIST_HEADERS_REQUEST.

Run:

🏁 Script executed:

#!/bin/bash
# Verify the allowlist includes the new headers
rg -nP -C3 'const\s+FUNCTION_ALLOWLIST_HEADERS_REQUEST|define\s*\(\s*[\'"]FUNCTION_ALLOWLIST_HEADERS_REQUEST'
rg -nP -C1 'x-appwrite-execution-id|x-appwrite-client-ip'

Length of output: 116

I’ll re-run the search with proper quoting and broaden the context to ensure we find the constant definition and its contents:

🏁 Script executed:

#!/bin/bash
# 1) Locate where FUNCTION_ALLOWLIST_HEADERS_REQUEST is defined
rg -n --type=php "FUNCTION_ALLOWLIST_HEADERS_REQUEST" -C3

# 2) Inspect that definition for the two new headers
#    (display up to 10 lines around the definition and filter for our headers)
rg -n --type=php "FUNCTION_ALLOWLIST_HEADERS_REQUEST" -C10 | rg -n -F "'x-appwrite-execution-id'"
rg -n --type=php "FUNCTION_ALLOWLIST_HEADERS_REQUEST" -C10 | rg -n -F "'x-appwrite-client-ip'"

Length of output: 3741

@vermakhushboo Looking at the code, I can confirm my comment is accurate. In the fail() method:

1. Method signature has no $headers parameter: The method signature is private function fail(string $message, Database $dbForProject, Document $function, string $trigger, string $path, string $method, Document $user, string $jwt = null, string $event = null,): void

2. First use of $headers is an assignment: Line 268 shows $headers['x-appwrite-execution-id'] = $executionId ?? ''; without any prior initialization

3. PHP behavior: This relies on PHP's implicit array creation, which works but generates a notice in strict error reporting and is not considered best practice

4. Later usage confirms it's treated as array: The method later uses foreach ($headers as $key => $value) confirming $headers is expected to be an array

The fix I suggested ($headers = []; before the first assignment) would explicitly initialize the array and eliminate any potential PHP notices while maintaining the same functionality.

My comment and suggested fix are correct and should be applied for cleaner, more explicit code.

🏁 Script executed:

#!/bin/bash
# Let's verify the fail() method implementation to confirm $headers initialization
ast-grep --pattern $'private function fail(
  $$$
) {
  $$$
}'

Length of output: 63

@vermakhushboo I can now definitively verify my comment is correct. Looking at the fail() method implementation:

The issue confirmed:

• Line 267: $executionId = ID::unique();
• Line 268: $headers['x-appwrite-execution-id'] = $executionId ?? ''; ← First use of $headers without initialization
• Lines 269-272: More assignments to $headers array elements
• Line 280: foreach ($headers as $key => $value) ← Used as an array later

The problem:
The $headers variable is used as an array starting at line 268 without being explicitly declared/initialized first. This relies on PHP's implicit array creation behavior.

My suggested fix is correct: Adding $headers = []; before line 268 would explicitly initialize the array, following PHP best practices and avoiding any potential notices in strict error reporting modes.

The comment and suggested fix are accurate and should be implemented for cleaner, more maintainable code.

🏁 Script executed:

#!/bin/bash
# Search for the fail() method implementation
rg -n -A 20 "private function fail" src/Appwrite/Platform/Workers/Functions.php

Length of output: 894

• File: src/Appwrite/Event/Event.php

  • Lines: 10-593
  • Summary:
    • Defines the central Event system used by all workers.
    • Key concepts:
      • Event constants for queue names and class names (e.g., DATABASE_QUEUE_NAME, ... FUNCTIONS_QUEUE_NAME, etc.).
      • Properties for queue, class, event, payload, context, project, user, userId, etc.
      • preparePayload(): builds a payload including project, user, type, collection, document, database, and generated events.
      • trigger(): enqueues the prepared payload to the appropriate queue, with error handling that respects the critical flag.
      • preparePayload merges base payload with trimmed values and supports masking sensitive info.
      • Static generateEvents(pattern, params): expands a base event pattern into all concrete events, substituting placeholders with provided params or wildcards, validating required params, and returning an array of event strings.
      • parseEventPattern(pattern): parses a single event pattern into its components (type, resource, subResource, action, etc.).
      • from(Event): copies state from another Event instance.
    • Notable behavior:
      • If an event is non-critical and enqueue fails, trigger() returns false instead of throwing.
      • The event-generation logic supports complex nested resources and placeholders.

• File: src/Executor/Executor.php

  • Lines: 10-459
  • Summary:
    • Provides runtime orchestration for executing functions/deployments.
    • Key methods:
      • createRuntime(projectId, deploymentId, source, image, version, cpus, memory, timeout, ...): deploys a runtime container for execution and returns runtime metadata.
      • getLogs(deploymentId, projectId, timeout, callback): streams logs from a runtime.
      • deleteRuntime(projectId, deploymentId, suffix): deletes a runtime instance.
      • createExecution(projectId, deploymentId, body, variables, timeout, image, source, entrypoint, version, path, method, headers, cpus, memory, logging, runtimeEntrypoint, requestTimeout): creates and starts an execution request for a deployment.
        • Builds a request payload with runtimeId, variables, timeout, path, method, headers, image, source, entrypoint, resources, version, and additional fields.
        • Sends request to /runtimes/{runtimeId}/executions via HTTP (multipart/form-data).
        • Validates HTTP status, decodes response, and normalizes headers/duration/startTime in the response body.
      • createCommand(...): creates a runtime command.
      • Private call(endpoint, method, path, headers, params, decode, timeout, callback): low-level HTTP client using curl.
        • Supports JSON and multipart/form-data body formats.
        • Handles streaming callbacks, response parsing, and error propagation.
        • Decodes JSON/multipart responses, extracts status codes, and surfaces errors.
    • Notable behavior:
      • Throws on HTTP error statuses (>= 400) with the status code.
      • Supports self-signed certificates via a flag.
      • Returns structured response body containing statusCode, headers, body, duration, etc.

• File: src/Appwrite/Platform/Workers/StatsUsage.php

  • Lines: 16-481
  • Summary:
    • Stats usage worker collects and aggregates usage metrics per project.
    • Key aspects:
      • getName(): returns 'stats-usage'.
      • Constructor wires in dependencies and sets up the callback for the action.
      • action(Message $message, callable $getProjectDB, callable $getLogsDB, Registry $register): core entrypoint.
        • Aggregates metrics from payload['metrics'] and reduces per project using payload['reduce'] data.
        • Batches metrics and commits to DB when thresholds are reached or interval elapses.
        • Maintains internal state: $stats, $lastTriggeredTime, $keys, and $projects for batched writes.
      • commitToDb(callable $getProjectDB): writes batched stats into each project’s DB using stats collection; also triggers logs writing for usage data.
      • prepareForLogsDB()/writeToLogsDB(): optionally dual-writes metrics to logs DB depending on environment variable _APP_STATS_USAGE_DUAL_WRITING.
      • Maintains a set of base metrics to skip from dual-writing (skipBaseMetrics) and a set of metrics to avoid parent-id variants (skipParentIdMetrics).
    • Notable behavior:
      • Aggregates and persists metrics such as deployments, builds, executions, storage, and more across time periods (1h, 1d, inf).
      • Designed for batch writes to improve performance.

• File: src/Appwrite/Event/Database.php

  • Lines: 9-142
  • Summary:
    • Defines a Database event type used by the database-related workers.
    • Key methods:
      • setType(string $type): self
      • getType(): string
      • setDatabase(Document $database): self
      • getDatabase(): ?Document
      • setCollection(Document $collection): self
      • getCollection(): ?Document
      • setDocument(Document $document): self
      • getDocument(): ?Document
      • getQueue(): string
      • preparePayload(): array
    • preparePayload() returns a payload including project, user, type, collection, document, database, and events generated via Event::generateEvents($this->getEvent(), $this->getParams()).
    • Notable behavior:
      • getQueue() derives a queue name from the project's database DSN, with a fallback for legacy setups (namespace-based queue naming).

• File: src/Appwrite/Event/Realtime.php

  • Lines: 47-51
  • Code (complete snippet):
    public function setSubscribers(array $subscribers): self
    {
    $this->subscribers = $subscribers;
    return $this;
    }

• File: src/Appwrite/Platform/Workers/Webhooks.php

  • Lines: 22-25
  • Code (complete snippet):
    public static function getName(): string
    {
    return 'webhooks';
    }