Skip to content

Conversation

@GunaPalanivel
Copy link
Contributor

@GunaPalanivel GunaPalanivel commented Dec 18, 2025

Related Issues

Part of #2605

Description

This PR exposes the refresh parameter to relevant methods in OpenSearchDocumentStore, allowing users to control when index changes become visible to search operations.

Motivation

OpenSearch is a "near real-time" search engine where changes are not immediately visible after write/update/delete operations. Previously, users had to use time.sleep() workarounds to ensure consistency. This change exposes the underlying refresh parameter, giving users explicit control over this behavior.

Changes

New RefreshType parameter added to the following methods:

Method Default Value
write_documents / write_documents_async "wait_for"
delete_documents / delete_documents_async "wait_for"
delete_all_documents / delete_all_documents_async True
delete_by_filter / delete_by_filter_async "wait_for"
update_by_filter / update_by_filter_async "wait_for"

Parameter values:

  • True: Force refresh immediately after the operation
  • False: Do not refresh (better performance for bulk operations)
  • "wait_for": Wait for the next refresh cycle (default, ensures read-your-writes consistency)

Test Updates

Updated integration tests to use refresh=True instead of time.sleep(), making tests more reliable and faster.

Additional Fixes

  • Fixed delete_all_documents_async to set wait_for_completion=True, ensuring the async delete operation completes before returning

How was this tested?

  • Existing integration tests updated to use the new refresh parameter
  • All tests pass with the new implementation

Add configurable refresh parameter to write, delete, and update methods
in OpenSearchDocumentStore.

This allows users to control when index changes become visible to search
operations, enabling read-your-writes consistency without relying on
time.sleep() workarounds.

Methods updated:
- write_documents / write_documents_async
- delete_documents / delete_documents_async
- delete_all_documents / delete_all_documents_async
- delete_by_filter / delete_by_filter_async
- update_by_filter / update_by_filter_async

The refresh parameter accepts:
- True: Force immediate refresh
- False: No refresh (best for bulk performance)
- 'wait_for': Wait for next refresh cycle (default)

Additional fix:
- Fixed delete_all_documents_async to set wait_for_completion=True,
  ensuring the async delete operation completes before returning

Closes deepset-ai#2065
@GunaPalanivel GunaPalanivel requested a review from a team as a code owner December 18, 2025 16:33
@GunaPalanivel GunaPalanivel requested review from vblagoje and removed request for a team December 18, 2025 16:33
@github-actions github-actions bot added integration:opensearch type:documentation Improvements or additions to documentation labels Dec 18, 2025
@anakin87
Copy link
Member

Thanks for opening a separate PR. Let's put this on hold and first agree on #2622

@anakin87
Copy link
Member

@GunaPalanivel when you have time, feel free to adapt this PR based on #2622 🙂

@GunaPalanivel
Copy link
Contributor Author

@anakin87

I'm working on it 🙂

@GunaPalanivel
Copy link
Contributor Author

Based on #2622 , I've adapted this PR for OpenSearch:

Main changes:

  • Split refresh parameter types: Literal[True, False, "wait_for"] for write/delete methods, bool for delete_by_query/update_by_query operations (since they don't support "wait_for")
  • Set refresh="wait_for" as default for write_documents and delete_documents
  • Kept refresh=True for delete_all_documents and filter-based operations
  • Added proper OpenSearch API doc links to all refresh parameters
  • Updated tests to use refresh=True instead of time.sleep() hacks

Let me know if I missed anything or got something wrong, happy to fix! 🙂

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

Labels

integration:opensearch type:documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants