fix(timeout): respect insertion timeout from config for fixed_batch

[jpsoultanis]

Summary

There's a bug where the Weaviate Python client SDK doesn't respect the config.Timeout for batch insertions. This issue dates back a while.

_BatchBase.__send_batch passes a hardcoded DEFAULT_REQUEST_TIMEOUT = 180 as the gRPC deadline for BatchObjects [src]:

DEFAULT_REQUEST_TIMEOUT = 180

# ... 

self.__batch_grpc.objects(
    connection=self.__connection,
    objects=[obj._to_internal() for obj in objs],
    timeout=DEFAULT_REQUEST_TIMEOUT,  # <-----------------------
    max_retries=MAX_RETRIES,
)

This silently ignores set values in config additional_config.timeout.insert. Ex:

weaviate.connect_to_custom(
   ...   
   additional_config=weaviate.config.AdditionalConfig(
      timeout=weaviate.config.Timeout(insert=600),  # Values in seconds <-----------------
   ),
)

The change in this PR makes it honor the configured Timeout.insert config value, matching the sibling code paths (batch deletion, insert_many).

Context

Timeout.insert is already honored by other write paths:

• _DataExecutor.insert_many — weaviate/collections/data/executor.py:216
• grpc_batch_delete (sync) — weaviate/connect/v4.py:1048
• grpc_batch_delete (async) — weaviate/connect/v4.py:1230

__send_batch in weaviate/collections/batch/base.py was the odd one out.

Behavior change

This PR as-is comes with an important behavioral change in the default case. The default Timeout.insert is 90s (weaviate/config.py:59). Users on the default configuration will now see a 90s gRPC insertion deadline on BatchObjects instead of the previous 180s. This makes the Timeout.insert field actually reflect the value used at the call site, at the cost of a tighter default.

If 90s turns out to be too tight specifically for batch with server-side vectorizers, this requires further discussion by Weaviate maintainers. We could potentially raise this default to 180s to match the previous default, but this comes with additional tradeoffs to consider.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[weaviate-git-bot]

To avoid any confusion in the future about your contribution to Weaviate, we work with a Contributor License Agreement. If you agree, you can simply add a comment to this PR that you agree with the CLA so that we can merge.

beep boop - the Weaviate bot 👋🤖

PS:
Are you already a member of the Weaviate Forum?

[jpsoultanis-kapa]

I agree with the CLA