Issue Station
Sign In
Tools hereToolbox

dify - ✅(Solved) Fix Flaky CI failure in WordExtractor close test [2 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
langgenius/dify#35651•Fetched 2026-04-29 06:36:18
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
1
Author
kenwoodjwkenwoodjw
Participants
kenwoodjwkenwoodjw
Timeline (top)
cross-referenced ×2closed ×1labeled ×1

Error Message

github action error below

Root Cause

This is hard to reproduce locally because it depends on test order and garbage collection timing.

Fix Action

Fixed

PR fix notes

PR #35652: fix: flaky WordExtractor close test in CI

Description (problem / solution / changelog)

[!IMPORTANT]

  1. Make sure you have read our contribution guidelines
  2. Ensure there is an associated issue and you have been assigned to it
  3. Use the correct syntax to link this PR: Fixes #<issue number>.

Summary

Fixes #35651 close https://github.com/langgenius/dify/pull/35654

<!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> <!-- If this PR was created by an automated agent, add `From <Tool Name>` as the final line of the description. Example: `From Codex`. -->

Screenshots

BeforeAfter
......

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint && make type-check (backend) and cd web && pnpm exec vp staged (frontend) to appease the lint gods

Changed files

  • api/tests/unit_tests/core/rag/extractor/test_word_extractor.py (modified, +10/-14)

PR #35654: test: make WordExtractor close test deterministic

Description (problem / solution / changelog)

Summary

  • Makes WordExtractor.close() coverage deterministic.
  • Replaces a runtime-warning based AsyncMock/GC assertion with a direct awaitable close-result stub.
  • Keeps the test focused on the extractor behavior instead of unrelated coroutine cleanup timing.
  • Removes now-unused gc, warnings, and AsyncMock imports.

Why

The previous test could observe coroutine warnings emitted by earlier tests, which made the assertion flaky and unrelated to WordExtractor.close() itself.

Validation

  • python3 -m py_compile api/tests/unit_tests/core/rag/extractor/test_word_extractor.py

Not run: targeted pytest, because dependency setup failed locally with No space left on device while downloading packages.

Fixes #35651 close https://github.com/langgenius/dify/pull/35652

Changed files

  • api/tests/unit_tests/core/rag/extractor/test_word_extractor.py (modified, +14/-14)

Code Example

FAILED api/tests/unit_tests/core/rag/extractor/test_word_extractor.py::test_close_handles_async_close_mock - assert not [<warnings.WarningMessage object at 0x7f2eb5509940>]
RAW_BUFFERClick to expand / collapse

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

main

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The API unit test sometimes fails in CI:

test_close_handles_async_close_mock RuntimeWarning: coroutine 'AsyncMockMixin._execute_mock_call' was never awaited

This is hard to reproduce locally because it depends on test order and garbage collection timing.

The test used gc.collect() inside warnings.catch_warnings(). This can catch warnings from async mock coroutines leaked by earlier tests in the same pytest worker, not only warnings from this test.

✔️ Expected Behavior

The test should only check WordExtractor.close() behavior.

❌ Actual Behavior

FAILED api/tests/unit_tests/core/rag/extractor/test_word_extractor.py::test_close_handles_async_close_mock - assert not [<warnings.WarningMessage object at 0x7f2eb5509940>]

github action error below https://github.com/langgenius/dify/actions/runs/25037138795/job/73331450574 https://github.com/langgenius/dify/actions/runs/25055872851/job/73396113155

The test can fail because it captures unrelated warnings from previous tests.

extent analysis

TL;DR

The test failure can be addressed by ensuring that the test only captures warnings related to the current test, rather than warnings from previous tests.

Guidance

  • Review the test code to ensure that warnings.catch_warnings() is properly scoped to only capture warnings from the current test.
  • Consider using a context manager to ensure that warnings are properly reset after each test.
  • Investigate the use of gc.collect() inside warnings.catch_warnings() and consider alternative approaches to avoid capturing unrelated warnings.
  • Examine the test order and consider reordering tests to minimize the impact of garbage collection timing on test results.

Example

import warnings

with warnings.catch_warnings(record=True) as w:
    # test code here
    # ...

This example uses a context manager to capture warnings and ensure they are properly reset after the test.

Notes

The issue is likely due to the test capturing unrelated warnings from previous tests, which can be addressed by properly scoping the warning capture. However, the exact solution may depend on the specific test code and requirements.

Recommendation

Apply workaround: properly scope warning capture to ensure that only warnings related to the current test are captured. This can help to minimize the impact of unrelated warnings on test results.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING