Patch and overloads should support returning some kind of status.

[niemyjski]

If you cannot patch or the update by query with script ends up being a noop, you have no way to know if something actually updated. We take action on a patch sometimes especially around logging but the action may not have done anything.

I think we should at least return a count from the patch of records modified.

[niemyjski]

Design Recommendation: Return Patch Status via bool / long

Problem

PatchAsync(Id, ...) and PatchAsync(Ids, ...) currently return bare Task (void). When a script-based or partial-doc patch results in a noop (no actual change), callers have no way to know. This matters for logging, auditing, and conditional side-effects — you may take action after a patch that didn't actually modify anything.

PatchAllAsync(query, ...) already returns Task<long> and correctly excludes noops in its UpdateByQuery code path, so no interface change is needed there.

Elasticsearch API Research

Elasticsearch provides noop/modified status at different granularities depending on the API:

API	Noop Detection	Granularity	Docs
Update API (single doc)	response.result field: updated, noop, created, deleted, not_found	Per-document	Update API docs
Bulk API (multi-doc by IDs)	Per-item result field on each BulkResponseItem — same values as Update API	Per-document	Bulk API docs
Update By Query API (query-based)	Aggregate counts only: total, updated, noops, deleted, version_conflicts	Aggregate only — no per-document breakdown	Update By Query docs

Key detail: noop is returned when detect_noop: true (the default for Elasticsearch) and the document content didn't actually change. This applies to both ScriptPatch (when the script doesn't modify ctx._source) and PartialPatch (when the partial doc matches existing values).

Client Library Support

• NEST 7 (current): UpdateResponse<T>.Result is a typed enum with values including Result.Noop, Result.Updated, Result.Created. BulkResponseItem has a Result string property.
• Elastic.Clients.Elasticsearch v8/v9 (PR Upgrade to Elastic.Clients.Elasticsearch (ES 8.x) #216): UpdateResponse<T>.Result is a typed enum with Result.NoOp, Result.Updated, Result.Created (slightly different casing). BulkResponseItem.Result works the same way.

Proposed API

// Single doc: true = modified, false = noop (exceptions thrown on error)
Task<bool> PatchAsync(Id id, IPatchOperation operation, CommandOptionsDescriptor<T> options);
Task<bool> PatchAsync(Id id, IPatchOperation operation, ICommandOptions options = null);

// Multiple docs by IDs: count of documents actually modified (excludes noops)
Task<long> PatchAsync(Ids ids, IPatchOperation operation, CommandOptionsDescriptor<T> options);
Task<long> PatchAsync(Ids ids, IPatchOperation operation, ICommandOptions options = null);

// Query-based: already returns Task<long> — no change needed
Task<long> PatchAllAsync(IRepositoryQuery query, IPatchOperation operation, ICommandOptions options = null);

Why bool for single-doc?

• A single-doc patch is a yes/no question: "did this change anything?"
• long would be misleading since it can only be 0 or 1
• bool is idiomatic C# for single-item modification status
• Natural consumption: if (await repo.PatchAsync(id, op)) { LogChange(); }

Why long for multi-doc?

• Matches the existing PatchAllAsync, RemoveAllAsync, and BatchProcessAsync patterns which all return Task<long>
• Tells callers exactly how many documents were actually modified

Error Handling (No Change)

Errors continue to throw exceptions — the return value only communicates noop vs. modified on the success path:

• DocumentNotFoundException — document doesn't exist (HTTP 404)
• VersionConflictDocumentException — optimistic concurrency conflict (HTTP 409)
• DocumentException — any other Elasticsearch failure

Implementation per Code Path

Patch Type	Single Doc (PatchAsync(Id))	Multi Doc (PatchAsync(Ids))	Query (PatchAllAsync)
ScriptPatch	Check UpdateResponse.Result == Noop → false; otherwise true	Count Bulk items where result != "noop"	Already correct (UpdateByQuery updated count)
PartialPatch	Check UpdateResponse.Result == Noop → false; otherwise true	Count Bulk items where result != "noop"	Already correct
JsonPatch	Get-modify-reindex cycle → always true	Delegates to PatchAllAsync → already returns long	Get-modify-reindex → counts all processed
ActionPatch	Get-modify-reindex cycle → always true	Delegates to PatchAllAsync → already returns long	Get-modify-reindex → counts all processed

ES v9 PR #216 note: ScriptPatch with pipeline uses UpdateByQueryRequest instead of UpdateRequest — noop detected via response.Updated == 0. PartialPatch with pipeline uses get-merge-reindex — no ES-level noop detection (always returns true).

Internal Changes Needed

1. BulkResult (internal): Add NoopIds set to classify bulk items where result == "noop". Both NEST 7 and ES v9 BulkResponseItem expose a Result property for this.
2. PatchAllAsync task status extraction (ES v9 only): Add noops field extraction from the task status JSON for logging completeness.

Why NOT BulkWriteResult<T>

The earlier proposal for a BulkWriteResult<T> result object was reconsidered:

• Over-engineered for the core problem (noop detection) — the issue asks for "at least return a count"
• Doesn't match codebase patterns — no existing write operations return result objects; they return T, void, or long
• Would broaden scope — consistency would demand changing AddAsync, SaveAsync, RemoveAsync too
• Mixes concerns — partial failure handling already uses typed exceptions (DuplicateDocumentException, VersionConflictDocumentException), not result objects

Breaking Change Assessment

• Changing Task → Task<bool> / Task<long> is a binary-breaking change but source-compatible
• Existing code like await repo.PatchAsync(id, op) compiles and works unchanged (return value is discarded)
• Interface change requires recompilation of consumers

Files to Modify

1. src/Foundatio.Repositories/IRepository.cs — Change PatchAsync return types
2. src/Foundatio.Repositories/Models/IPatchOperation.cs — Update ActionPatchExtensions return types
3. src/Foundatio.Repositories.Elasticsearch/Repositories/ElasticRepositoryBase.cs — Capture response.Result / bulk item results and return counts
4. src/Foundatio.Repositories.Elasticsearch/Repositories/BulkResult.cs — Add NoopIds tracking
5. Tests — Verify noop returns false/0 and actual modifications return true/count