YAshhh29 commented on issue #71246:
URL: https://github.com/apache/airflow/issues/71246#issuecomment-5216001320
Tested `apache-airflow-providers-openai==1.8.2rc2` for #69534.
I installed the PyPI wheel in a clean Python 3.10.20 environment with
Airflow 3.1.3, OpenAI provider 1.8.2rc2, and OpenAI SDK 2.53.0.
`pip check` is clean. The wheel SHA-256 is
`c7b9e56d38b3edd914780e11a94e048c7905dfaf70999b7c2c1365d89c63f570`,
matching the PyPI artifact.
For #69534, I verified that:
- `OpenAITriggerBatchOperator` passes `timeout` to `OpenAIBatchTrigger`.
- The preferred `timeout` and legacy `end_time` forms both serialize
correctly.
- Supplying both arguments, or neither argument, is rejected.
- With monotonic time advancing `100 -> 101 -> 106`, the trigger reports
timeout after six elapsed seconds.
- A simulated wall-clock jump is never read by the RC timeout path.
- As a control, provider 1.8.1 reads wall time and times out early after
the same simulated jump.
I also confirmed that the dependency change from #69408 remains present:
the RC metadata requires plain `openai>=2.37.0` without the `datalib`
extra. The clean environment contains no `numpy`, `pandas`, or
`pandas-stubs`. This metadata change was already present in provider 1.8.1,
so this part is regression verification rather than an RC-versus-1.8.1
difference.
RC artifact checks: 9 passed.
Pre-fix comparison: 1 passed.
I used the clean-virtualenv contributor verification method. No live
OpenAI API call was made; this validates the published artifact's metadata,
serialization, validation, operator handoff, and timeout behavior.
No issues found in the tested scope.
---
Drafted-by: GitHub Copilot; reviewed by @YAshhh29 before posting
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
