Capybara attach_file测试异常：Turbo响应触发但未追加至页面

我有一个使用Cuprite驱动的Capybara文件字段测试，此前正常运行一年。原UI中Stimulus控制器捕获点击事件，加载文件后向Rails控制器发送请求并携带文件属性，获取HTML模板后手动追加至页面，填充图片data URI及文件名称、大小等字段。

目前我将控制器重构为返回turbo_stream响应：Turbo会将空白HTML前置到页面的div中，随后Stimulus控制器监听targetConnected事件并像之前一样填充模板，该逻辑在浏览器中运行正常。

但在系统测试中，断言追加元素存在的逻辑失败；headless模式下无任何反应，Rails及控制台均无报错。起初我怀疑attach_file或输入框点击失效，但已确认文件已成功上传，请求也携带正确的文件属性参数；断点调试控制器动作及turbo_stream模板均无问题。

现在发现：尽管文件已上传且Turbo响应已触发，但流HTML从未被前置到div中，即使断言添加wait:6（或更长时间）也无效，仅约5%的概率断言成功。请问可能的原因是什么？

相关代码 #

系统测试代码

# system test
label = first(".file-field")
scroll_to(label, align: :center)
attach_file("select_images_button",
            Rails.root.join("test/images/#{filename}"),
            make_visible: true)

assert_selector(".added_image_wrapper", text: /image_caption/)

Rails控制器Turbo响应代码

# controller#new
<%=
turbo_stream.prepend(
  "added_images",
  partial: "controller/form/images/carousel_item",
  locals: { upload: true, index: params[:index],
            img_id: params[:img_id],
            img_file_name: params[:img_file_name],
            img_file_size: params[:img_file_size] }
)
%>

注：轮播项模板确实包含.added_image_wrapper类。

• Turbo流处理时序不匹配：Cuprite的headless环境中，Turbo处理响应的速度比浏览器慢，或者Stimulus的targetConnected事件触发时机和测试断言时机错位。即便加了wait:6，也可以尝试在断言前明确等待Turbo的turbo:render事件完成，或者等待页面请求全部结束（比如调用wait_for_requests方法），确保Turbo响应已被处理。
• Cuprite与Turbo的兼容性bug：部分版本的Cuprite在headless模式下对Turbo Stream的处理存在隐性问题。可以尝试升级cuprite gem、Chromium以及相关依赖，看看是否能修复该问题。
• 元素定位的竞态条件：first(".file-field")可能获取到不稳定的元素，或者attach_file刚完成就执行断言，此时Turbo还未开始处理响应。可以在上传操作后添加短暂等待，或者先断言目标容器added_images存在，再执行上传。
• Turbo目标元素异常：确认测试执行时added_images这个div确实存在，且没有被其他操作修改或移除。测试环境的DOM结构可能和生产环境有细微差异，导致Turbo找不到目标元素而静默失败。
• Stimulus控制器初始化问题：headless环境中，Stimulus可能未正确绑定targetConnected事件，或者Turbo插入元素后，Stimulus未及时识别新元素。可以尝试在测试中手动触发Stimulus初始化，或者检查控制器的connect方法是否适配动态插入的元素。
• Cuprite headless配置问题：如果配置中禁用了JavaScript、限制了内存或资源加载，会影响Turbo正常运行。检查Cuprite初始化配置，确保JavaScript启用，且无不合理的资源限制。

内容的提问来源于stack exchange，提问作者nimmolo