Add Change Feed Processor (CFP) support for JavaScript/Node.js

[paulo-assoc]

Add Change Feed Processor (CFP) support for JavaScript/Node.js

Problem

Reading changes across many partitions in a reactive way is difficult to do because you can only query by partition key. I am always frustrated when a programming language (in this case C#/.NET and Java) is given preferential treatment. I believe there a large number of JavaScript developers using Cosmos DB. We want and need all Cosmos DB features to be available to us. I realize this feature request was proposed by a contributor, ignored, and then closed previously.

Proposed solution

Change Feed Processor pattern allows for subscribing on all changes across many machines, for better throughput.

Next steps

Start planning support for it

[github-actions]

🎯 Agentic Issue Triage

Summary: The author is requesting that the @azure/cosmos JavaScript SDK add support for the Change Feed Processor (CFP) pattern, a feature already available in other SDK languages (C#/.NET and Java) that enables subscribing to changes across many partitions for high-throughput reactive scenarios.

📋 Issue Details

Package: @azure/cosmos (latest: 4.9.3)
Affected API: Change Feed — partition-level and cross-partition iteration
Scenarios:

• Reactive consumption of changes across many Cosmos DB partitions
• High-throughput multi-machine scale-out change processing using CFP

Root ask: Implement the Change Feed Processor (CFP) pattern in the JavaScript SDK, on par with the C#/.NET and Java SDKs.

🔎 Debugging / Reproduction Notes

This is a feature request, not a bug report. The current @azure/cosmos SDK exposes a basic Change Feed iterator but does not implement the full Change Feed Processor pattern (lease management, distributed processing across multiple workers).

Suggested investigation steps:

1. Review current change feed support in @azure/cosmos — items.getChangeFeedIterator() and container.getChangeFeedIterator().
2. Compare parity with the C# [ChangeFeedProcessor]((learn.microsoft.com/redacted) and Java equivalents.
3. Assess whether the lease-container-based CFP pattern can be layered on top of the existing change feed iterator primitives.

🏷️ Label Confidence

• Category: Client — This is a data-plane SDK feature request for @azure/cosmos, a client library under /sdk/cosmosdb/.
• Service: Cosmos — Issue explicitly targets Azure Cosmos DB functionality (Change Feed Processor).
• Confidence: High — The package (@azure/cosmos) and service (Cosmos DB) are unambiguous; the category (Client, not Mgmt) is clear. Validated against reference issue Failed to fetch the response from Cosmos DB #16670 which carries identical Client + Cosmos labels.

👥 Owner Routing

• Matched CODEOWNERS entry: None — no single # ServiceLabel: %Cosmos entry exists.
• AzureSdkOwners: none listed
• ServiceOwners: none matched
• Routing action: Added needs-team-triage for manual owner assignment.
• Scan notes (bottom-to-top):
  • Line 1541 # ServiceLabel: %Azure.Spring - Cosmos — different label name, no match.
  • Line 195 # ServiceLabel: %Cosmos %Service Attention — requires both %Cosmos AND %Service Attention; this issue does not carry "Service Attention", so no match.
  • No remaining # ServiceLabel: %Cosmos (single-label) entry found in the file.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• releaseassets.githubusercontent.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "releaseassets.githubusercontent.com"

See Network Configuration for more information.

Generated by Agentic Triage for issue #38328 · ● 820K · ◷

[sajeetharan]

Thanks @paulo-assoc we will take a look!