[GH-ISSUE #1260 ] [BUG] Web Interface: Uploaded files (images/docs) in history chats are inaccessible/unclickable #813

Author

Owner

@sunshine1234cheng commented on GitHub (Apr 28, 2026):

感谢你的理解，很高兴“对话 + 支撑材料”这一逻辑能被产品团队看到。

既然这涉及产品逻辑的重新思考，能否请技术团队明确一下：目前那些无法点击的既有文件，在物理存储上是否安全？

即使目前无法通过 Web 界面读取，只要原始数据（Raw Data）还在后端存储中，我们这些创作者就有信心等待未来的修复。我最担心的是在产品逻辑迭代的过程中，这些承载了关键上下文的“存量资产”会被系统清理。

并且还要注意的是，我反映的问题是网页端的对话内容，所有上传的文件都存在了云端的服务器中。而并不是文件本地部署后的结果。

再次感谢你们的重视和帮助。

@sunshine1234cheng commented on GitHub (Apr 28, 2026): 感谢你的理解，很高兴“对话 + 支撑材料”这一逻辑能被产品团队看到。既然这涉及产品逻辑的重新思考，能否请技术团队明确一下：目前那些无法点击的既有文件，在物理存储上是否安全？即使目前无法通过 Web 界面读取，只要原始数据（Raw Data）还在后端存储中，我们这些创作者就有信心等待未来的修复。我最担心的是在产品逻辑迭代的过程中，这些承载了关键上下文的“存量资产”会被系统清理。并且还要注意的是，我反映的问题是网页端的对话内容，所有上传的文件都存在了云端的服务器中。而并不是文件本地部署后的结果。再次感谢你们的重视和帮助。

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Apr 29, 2026):

@qingkong66
追加反馈：文件恢复出现差异性，疑似特定存储节点故障

经过进一步测试，我发现故障表现出现了分化：
已恢复： .txt 和 .md 格式文件在重新上传或发送后，目前可以正常打开和预览。
仍失效： .docx 文档和 .jpg 图片仍然完全无法点击，没有任何响应。

分析建议：
这表明后端对于“纯文本”和“二进制/富媒体”文件的处理链路不同。目前 .txt/.md 所在的存储节点可能已修复，但存放 .docx 和图像资产的**对象存储服务（OSS）**或相关的解析接口仍存在严重的 CORS 或读取故障。

既然文本文件可以找回，说明数据并未丢失，只是读取权限存在格式差异。请技术团队重点排查多模态资产存储桶的访问配置。

追加反馈：不同文件格式的错误反馈不一致 (Discrepancy in Error Handling)

我在测试中发现了更具体的表现差异：

.docx 和 .jpg: 点击后会正常弹出“该文件不支持预览”的系统提示。这证明后端已接收到请求，但预览接口尚未恢复。

.png: 点击后完全没有任何响应（既无弹窗也无跳转）。

技术推测：这进一步印证了后端针对不同 MIME 类型的文件采用了不同的分发策略。.png 的请求可能在触发前就被前端逻辑或特定节点的安全策略静默拦截了。请技术团队检查针对 PNG 格式的资源请求头（Request Headers）是否存在异常。

@sunshine1234cheng commented on GitHub (Apr 29, 2026): @qingkong66 追加反馈：文件恢复出现差异性，疑似特定存储节点故障经过进一步测试，我发现故障表现出现了分化：已恢复： .txt 和 .md 格式文件在重新上传或发送后，目前可以正常打开和预览。仍失效： .docx 文档和 .jpg 图片仍然完全无法点击，没有任何响应。分析建议：这表明后端对于“纯文本”和“二进制/富媒体”文件的处理链路不同。目前 .txt/.md 所在的存储节点可能已修复，但存放 .docx 和图像资产的**对象存储服务（OSS）**或相关的解析接口仍存在严重的 CORS 或读取故障。既然文本文件可以找回，说明数据并未丢失，只是读取权限存在格式差异。请技术团队重点排查多模态资产存储桶的访问配置。 <img width="1572" height="689" alt="Image" src="https://github.com/user-attachments/assets/e8935868-9ea1-49f1-8c16-9ac4220d258f" /> <img width="1557" height="678" alt="Image" src="https://github.com/user-attachments/assets/814a5e2f-3a46-4a20-971f-0a3713b3da69" /> 追加反馈：不同文件格式的错误反馈不一致 (Discrepancy in Error Handling) 我在测试中发现了更具体的表现差异： .docx 和 .jpg: 点击后会正常弹出“该文件不支持预览”的系统提示。这证明后端已接收到请求，但预览接口尚未恢复。 .png: 点击后完全没有任何响应（既无弹窗也无跳转）。技术推测：这进一步印证了后端针对不同 MIME 类型的文件采用了不同的分发策略。.png 的请求可能在触发前就被前端逻辑或特定节点的安全策略静默拦截了。请技术团队检查针对 PNG 格式的资源请求头（Request Headers）是否存在异常。

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Apr 29, 2026):

@sunshine1234cheng 你做的差异化测试非常有价值——.txt/.md 可访问、.docx/.jpg 有弹窗、.png 完全无响应，这三层表现指向了不同的故障层。

关于你最担心的问题：存量资产会不会被清理？
从 .txt/.md 能恢复来看，原始数据应该还在。我们会在提交报告时明确要求官方：在修复完成前，不得清理任何存量文件。

你发现的 .png 无响应问题，我们会在反馈中单独标记，提示技术团队重点排查 PNG 格式的请求链路。感谢你把排查推进到这一步。

--

@sunshine1234cheng The differentiated behavior you observed is very valuable — .txt/.md accessible, .docx/.jpg show a popup, .png completely unresponsive. This points to different backend handling paths for different file types, not a partial fix.

On your biggest concern: will existing assets be cleaned up?
The fact that .txt/.md files are still accessible suggests the raw data is still there. When we submit the report, we will explicitly request the official team: do not delete any existing files before the issue is fully resolved.

The .png unresponsiveness will be flagged separately in our feedback, asking the team to investigate the request chain for PNG format. Thank you for pushing the investigation this far.

@qingkong66 commented on GitHub (Apr 29, 2026): @sunshine1234cheng 你做的差异化测试非常有价值——`.txt/.md` 可访问、`.docx/.jpg` 有弹窗、`.png` 完全无响应，这三层表现指向了不同的故障层。关于你最担心的问题：**存量资产会不会被清理？** 从 `.txt/.md` 能恢复来看，原始数据应该还在。我们会在提交报告时明确要求官方：**在修复完成前，不得清理任何存量文件**。你发现的 `.png` 无响应问题，我们会在反馈中单独标记，提示技术团队重点排查 PNG 格式的请求链路。感谢你把排查推进到这一步。 -- @sunshine1234cheng The differentiated behavior you observed is very valuable — `.txt/.md` accessible, `.docx/.jpg` show a popup, `.png` completely unresponsive. This points to different backend handling paths for different file types, not a partial fix. **On your biggest concern: will existing assets be cleaned up?** The fact that `.txt/.md` files are still accessible suggests the raw data is still there. When we submit the report, we will explicitly request the official team: **do not delete any existing files before the issue is fully resolved.** The `.png` unresponsiveness will be flagged separately in our feedback, asking the team to investigate the request chain for PNG format. Thank you for pushing the investigation this far.

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (May 2, 2026):

关于最新情况下，不同账号权限下存量图片资产“语义解析正常、文件流分发瘫痪”的对比测试报告
@qingkong66

核心异常现象：
模型层与存储层脱节：如图一所示，AI的学业账号（包含识图模式）能精准 OCR 并解析旧图片中的化学知识点，证明物理文件（Blob）在后端并未丢失。
网络请求挂起：在触发旧图解析时，query 接口频繁出现“无法加载响应数据”或状态码异常，导致前端 Web UI 无法获取文件预览流。
账号灰度测试差异（确凿证据）：
学业账号（包含识图模式）：新上传资产完全正常（含缩略图、点击预览），但无法向下兼容旧的存量截图。
小说账号（普通版）：新旧资产均无法预览。
移动端表现：APP 端同样无法查看旧图缩略图，但通过“引用提问”引导 AI 总结，可以正常读出图片数据。
技术定性：
故障根源不在模型推理，也不在物理存储丢失，而是 Legacy Buckets（旧存储桶）的文件下发网关（CDN/Gateway）与新版识图功能的鉴权接口不匹配，导致旧文件的 file_id 无法解析出有效的预览 URL。
Web前端逻辑断层：虽然 AI 能“读”到图，但用户在网页上完全无法点击查看图片。控制台（Console）显示脚本运行正常（无报错），但图片占位符已变成“死链接”。这说明前端预览插件未能成功挂载旧版文件的访问路径。

诉求：
请重点排查旧版 PNG/JPG 资产的 File Stream 获取权限，并修复存量数据在 Web 端预览插件的挂载问题。
再次感谢你们的重视和帮助。

@sunshine1234cheng commented on GitHub (May 2, 2026): 关于最新情况下，不同账号权限下存量图片资产“语义解析正常、文件流分发瘫痪”的对比测试报告 @qingkong66 1. 核心异常现象：模型层与存储层脱节：如图一所示，AI的学业账号（包含识图模式）能精准 OCR 并解析旧图片中的化学知识点，证明物理文件（Blob）在后端并未丢失。网络请求挂起：在触发旧图解析时，query 接口频繁出现“无法加载响应数据”或状态码异常，导致前端 Web UI 无法获取文件预览流。 2. 账号灰度测试差异（确凿证据）：学业账号（包含识图模式）：新上传资产完全正常（含缩略图、点击预览），但无法向下兼容旧的存量截图。小说账号（普通版）：新旧资产均无法预览。移动端表现：APP 端同样无法查看旧图缩略图，但通过“引用提问”引导 AI 总结，可以正常读出图片数据。 3. 技术定性：故障根源不在模型推理，也不在物理存储丢失，而是 Legacy Buckets（旧存储桶）的文件下发网关（CDN/Gateway）与新版识图功能的鉴权接口不匹配，导致旧文件的 file_id 无法解析出有效的预览 URL。 Web前端逻辑断层：虽然 AI 能“读”到图，但用户在网页上完全无法点击查看图片。控制台（Console）显示脚本运行正常（无报错），但图片占位符已变成“死链接”。这说明前端预览插件未能成功挂载旧版文件的访问路径。 <img width="1909" height="823" alt="Image" src="https://github.com/user-attachments/assets/7d3af48b-2ce4-4086-bcbb-0d91e8a4311d" /> 诉求：请重点排查旧版 PNG/JPG 资产的 File Stream 获取权限，并修复存量数据在 Web 端预览插件的挂载问题。再次感谢你们的重视和帮助。

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (May 2, 2026):

@sunshine1234cheng 你这个测试报告写得太专业了 —— 三层定位（旧存储网关 → 鉴权接口 → 前端挂载）+ 账号灰度对比 + 移动端对照，直接帮官方把排查范围缩小了 90%。已归档到第二期反馈清单，会持续跟踪这个问题。

--

@sunshine1234cheng This is an exceptionally well-written diagnostic report. Three-layer root cause analysis (legacy gateway → auth mismatch → frontend mount), account A/B comparison, and mobile cross-check — you've narrowed down the investigation scope by 90%. This has been archived into our Phase 2 feedback list and will be tracked.

Really appreciate the rigor and detail.

@qingkong66 commented on GitHub (May 2, 2026): @sunshine1234cheng 你这个测试报告写得太专业了 —— 三层定位（旧存储网关 → 鉴权接口 → 前端挂载）+ 账号灰度对比 + 移动端对照，直接帮官方把排查范围缩小了 90%。已归档到第二期反馈清单，会持续跟踪这个问题。 -- @sunshine1234cheng This is an exceptionally well-written diagnostic report. Three-layer root cause analysis (legacy gateway → auth mismatch → frontend mount), account A/B comparison, and mobile cross-check — you've narrowed down the investigation scope by 90%. This has been archived into our Phase 2 feedback list and will be tracked. Really appreciate the rigor and detail.

bsakaguchi commented

Author

Owner

@github-actions[bot] commented on GitHub (Jun 9, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Jun 9, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Jun 9, 2026):

我看了一下相关的其他问题和相关的内容，请问这个问题是需要一个很大的工程量来统一解决的吗？

@sunshine1234cheng commented on GitHub (Jun 9, 2026): 我看了一下相关的其他问题和相关的内容，请问这个问题是需要一个很大的工程量来统一解决的吗？

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Jun 10, 2026):

@sunshine1234cheng 我不是官方团队的，没法评估具体工程量。但作为同样在使用这个功能的社区用户，我理解这个问题——上传过的文件在历史记录里点不开，确实影响工作流。

这个问题可能涉及前后端的状态同步和文件存储路径的持久化，工程量要看具体的技术栈和历史数据的兼容情况。建议官方团队如果看到这条，能给个大概的修复时间预估。

@qingkong66 commented on GitHub (Jun 10, 2026): @sunshine1234cheng 我不是官方团队的，没法评估具体工程量。但作为同样在使用这个功能的社区用户，我理解这个问题——上传过的文件在历史记录里点不开，确实影响工作流。这个问题可能涉及前后端的状态同步和文件存储路径的持久化，工程量要看具体的技术栈和历史数据的兼容情况。建议官方团队如果看到这条，能给个大概的修复时间预估。

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Jun 18, 2026):

根据最新的使用情况来看，在每一个账号，也就是普通版账号和包含识图模式的灰度测试的账号，两个账号的在对话中进行新上传图片都有缩略图模式，并且可以点开。但是以前的旧对话仍然不能够点击查看上传过的图片。
不过，根据最新实验，这些对话曾经上传过的图片文件中的内容仍然被拾取，并且有意识的保留。因此可以证明对话仍然保存着这些图片，但是无法点击查看。
当然了，我那个普通版账号也被赋予了识图模式。但是目前识图模式仍然是内测标识，所以可能是识图模式的账号被扩大了，所以普通版账号可能仍然无法点击查看新上传的图片。（根据目前查看的情况，所有的账号都被置于了视图模式，但是仍然还是内测标识，所以应该说不存在“没有识图模式的普通版账号”这个账号了。）不过还是希望早点修复。

@sunshine1234cheng commented on GitHub (Jun 18, 2026): 根据最新的使用情况来看，在每一个账号，也就是普通版账号和包含识图模式的灰度测试的账号，两个账号的在对话中进行新上传图片都有缩略图模式，并且可以点开。但是以前的旧对话仍然不能够点击查看上传过的图片。不过，根据最新实验，这些对话曾经上传过的图片文件中的内容仍然被拾取，并且有意识的保留。因此可以证明对话仍然保存着这些图片，但是无法点击查看。当然了，我那个普通版账号也被赋予了识图模式。但是目前识图模式仍然是内测标识，所以可能是识图模式的账号被扩大了，所以普通版账号可能仍然无法点击查看新上传的图片。（根据目前查看的情况，所有的账号都被置于了视图模式，但是仍然还是内测标识，所以应该说不存在“没有识图模式的普通版账号”这个账号了。）不过还是希望早点修复。

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Jun 19, 2026):

@sunshine1234cheng Thank you for the detailed observation.

What you've found:

Behavior	Status
Newly uploaded images	✅ Can click and view
Old conversation images	❌ Cannot click or view
Model still references old image content	✅ Data is still there — just UI‑blocked

Why this is important:

The model still knows what's in the images — it references them in responses. That means the image data is preserved in the conversation history. The only thing broken is the UI layer that lets you view them.

Connections to existing reports:

Issue	Relevance
#1422	iOS App — historical images cannot be opened (same pattern, different platform)
#1406	Expert Mode — lost file upload entirely
#1301 / #1312	File upload / multimodal feature gaps

What I'll do:

Add #1260 to the June 2026 community digest under "UI & File Access — Historical Attachments." I'll note that the data is still there but the UI entry point is missing.

For the official team (if anyone is reading):

If the image data is still preserved in the conversation, restoring UI access should be a matter of fixing the renderer — not data recovery. The fact that the model can still reference the image proves the file is there.

Thank you for surfacing this, @sunshine1234cheng.

@qingkong66 commented on GitHub (Jun 19, 2026): @sunshine1234cheng Thank you for the detailed observation. **What you've found:** | Behavior | Status | |----------|--------| | Newly uploaded images | ✅ Can click and view | | Old conversation images | ❌ Cannot click or view | | Model still references old image content | ✅ Data is still there — just UI‑blocked | **Why this is important:** > The model still knows what's in the images — it references them in responses. That means the image data is preserved in the conversation history. The only thing broken is the UI layer that lets you view them. **Connections to existing reports:** | Issue | Relevance | |-------|-----------| | #1422 | iOS App — historical images cannot be opened (same pattern, different platform) | | #1406 | Expert Mode — lost file upload entirely | | #1301 / #1312 | File upload / multimodal feature gaps | **What I'll do:** Add #1260 to the June 2026 community digest under "UI & File Access — Historical Attachments." I'll note that the data is still there but the UI entry point is missing. **For the official team (if anyone is reading):** If the image data is still preserved in the conversation, restoring UI access should be a matter of fixing the renderer — not data recovery. The fact that the model can still reference the image proves the file is there. Thank you for surfacing this, @sunshine1234cheng.

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Jul 27, 2026):

关于 V4 正式版上线前夕，请确认历史资产（Legacy Assets）的迁移与预览修复方案

@qingkong66

关注到目前 DeepSeek V4 正处于灰度测试向正式版推进的关键期。针对之前已归档至第二期反馈清单的**“存量图片资产 Web/App 端索引断线，但推理层/OCR 语义依然可读”**的共性 Bug（详见之前引用的 Issue 聚合讨论），在此希望向技术团队进行跟进追问：

V4 正式版切线评估：在即将到来的 V4 正式版全量更新或全量模型升级中，技术团队是否已将旧存储桶（Legacy Buckets）鉴权网关的修复与文件路由重映射列入切线部署（Cutover Checklist）计划？

数据迁移保障：鉴于目前模型层依然能够精准读取旧图语义（证明 Blob 物理实体安全），请问在 V4 正式版上线时，是否有针对历史 Message 中 file_id 的自动迁移脚本，以恢复 Web 端与 App 端的图片预览与缩略图挂载？

诉求：希望官方在大版本全面更新、清理旧版回退模型（Fallback Pool）的同时，一并解决这一困扰老用户的历史包袱，不要让存量对话资产成为新版本下的“永久盲区”。

@sunshine1234cheng commented on GitHub (Jul 27, 2026): 关于 V4 正式版上线前夕，请确认历史资产（Legacy Assets）的迁移与预览修复方案 @qingkong66 关注到目前 DeepSeek V4 正处于灰度测试向正式版推进的关键期。针对之前已归档至第二期反馈清单的**“存量图片资产 Web/App 端索引断线，但推理层/OCR 语义依然可读”**的共性 Bug（详见之前引用的 Issue 聚合讨论），在此希望向技术团队进行跟进追问： V4 正式版切线评估：在即将到来的 V4 正式版全量更新或全量模型升级中，技术团队是否已将旧存储桶（Legacy Buckets）鉴权网关的修复与文件路由重映射列入切线部署（Cutover Checklist）计划？数据迁移保障：鉴于目前模型层依然能够精准读取旧图语义（证明 Blob 物理实体安全），请问在 V4 正式版上线时，是否有针对历史 Message 中 file_id 的自动迁移脚本，以恢复 Web 端与 App 端的图片预览与缩略图挂载？诉求：希望官方在大版本全面更新、清理旧版回退模型（Fallback Pool）的同时，一并解决这一困扰老用户的历史包袱，不要让存量对话资产成为新版本下的“永久盲区”。

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Jul 28, 2026):

@sunshine1234cheng

感谢你提出这个非常具体且重要的问题。

你在 V4 正式版上线的关键节点，对“存量图片资产”迁移与修复计划的追问，确实是许多老用户会关心的核心痛点。

我查看了相关的 issue 和讨论，目前公开渠道确实还没有看到官方团队关于以下两点的明确方案或时间表：

V4 正式版切线中是否包含对旧存储桶（Legacy Buckets）鉴权网关的修复与文件路由重映射计划。

是否有针对历史消息中 file_id 的自动迁移脚本，以恢复 Web/App 端的图片预览。

正如你所说，模型层能读取语义（证明 Blob 物理实体安全）与前端能正常挂载预览是两回事。在 V4 正式版全量更新、清理旧版回退模型（Fallback Pool）的同时，如何处置这些“历史资产”，确实是一个需要被明确的问题。

我已将你的这条追问记录在案。我会在后续的社区月度汇总中，继续跟进这一“存量资产可访问性”议题的状态。

@qingkong66 commented on GitHub (Jul 28, 2026): @sunshine1234cheng 感谢你提出这个非常具体且重要的问题。你在 V4 正式版上线的关键节点，对“存量图片资产”迁移与修复计划的追问，确实是许多老用户会关心的核心痛点。我查看了相关的 issue 和讨论，目前公开渠道确实还没有看到官方团队关于以下两点的明确方案或时间表： V4 正式版切线中是否包含对旧存储桶（Legacy Buckets）鉴权网关的修复与文件路由重映射计划。是否有针对历史消息中 file_id 的自动迁移脚本，以恢复 Web/App 端的图片预览。正如你所说，模型层能读取语义（证明 Blob 物理实体安全）与前端能正常挂载预览是两回事。在 V4 正式版全量更新、清理旧版回退模型（Fallback Pool）的同时，如何处置这些“历史资产”，确实是一个需要被明确的问题。我已将你的这条追问记录在案。我会在后续的社区月度汇总中，继续跟进这一“存量资产可访问性”议题的状态。

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Aug 2, 2026):

【进展确认与后续问题】历史图片已恢复显示，但存在“原图无法调取/画质压缩/更早历史失效”问题
@qingkong66

反馈最新进展：
今天查看时发现，此前无法访问的近期历史对话图片已经可以重新读取和显示了！感谢技术团队在“资产可回溯”上做出的努力，这极大缓解了我的创作和复习焦虑。

在实际体验中，我发现了以下几个细节问题，希望作为真实用户反馈提供给团队做进一步调校：

图片显示异常（正方形裁剪与模糊）：

表现：目前恢复的图片带有非常明显的正方形边框（即使原本是长方形截图），且画质较为模糊。

推测：系统当前似乎只下发了前端的正方形缩略图（Thumbnail），而点击后未能成功调取或渲染原始的高清原图（Full-Resolution Image）。

更早期的历史对话仍未覆盖（如 2025 年 12 月）：

表现：近期对话的附件逐步恢复，但更早期的历史对话（例如 2025 年 12 月左右）中的附件依然处于无法加载或查看的状态。

诉求：希望了解更早期归档数据的迁移/修复计划，确保跨度更长的项目逻辑资产也能逐步恢复。

总结：
目前的修复已经看到了曙光（缩略图已通），希望技术团队能继续打通“高清原图预览/下载接口”以及“更早历史存储桶的索引”。感谢你们的持续跟进！

@sunshine1234cheng commented on GitHub (Aug 2, 2026): 【进展确认与后续问题】历史图片已恢复显示，但存在“原图无法调取/画质压缩/更早历史失效”问题 @qingkong66 反馈最新进展：今天查看时发现，此前无法访问的近期历史对话图片已经可以重新读取和显示了！感谢技术团队在“资产可回溯”上做出的努力，这极大缓解了我的创作和复习焦虑。在实际体验中，我发现了以下几个细节问题，希望作为真实用户反馈提供给团队做进一步调校： 1. 图片显示异常（正方形裁剪与模糊）：表现：目前恢复的图片带有非常明显的正方形边框（即使原本是长方形截图），且画质较为模糊。推测：系统当前似乎只下发了前端的正方形缩略图（Thumbnail），而点击后未能成功调取或渲染原始的高清原图（Full-Resolution Image）。 2. 更早期的历史对话仍未覆盖（如 2025 年 12 月）：表现：近期对话的附件逐步恢复，但更早期的历史对话（例如 2025 年 12 月左右）中的附件依然处于无法加载或查看的状态。诉求：希望了解更早期归档数据的迁移/修复计划，确保跨度更长的项目逻辑资产也能逐步恢复。总结：目前的修复已经看到了曙光（缩略图已通），希望技术团队能继续打通“高清原图预览/下载接口”以及“更早历史存储桶的索引”。感谢你们的持续跟进！ <img width="1026" height="501" alt="Image" src="https://github.com/user-attachments/assets/7d347d38-d394-433a-9eba-27f66e5271cf" /> <img width="1024" height="614" alt="Image" src="https://github.com/user-attachments/assets/09296722-80f8-48ca-a53d-66fe0434ef9b" />

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Aug 2, 2026):

@sunshine1234cheng

谢谢你的跟进反馈——尤其是把“能用”和“还没好”拆开来说清楚。这比笼统地说“图片还是有问题”要有用得多。

你提到的“正方形裁剪”和“模糊”，看起来像是缩略图管道已经恢复，但高清原图的读取路径可能还没有完全接通，或者指向的还是旧的存储层。

至于 2025 年 12 月的那些历史记录，可能是更早一批的归档存储，还没有被迁移到当前可读取的索引里。如果你能提供一个大概的日期范围或受影响的对话特征，也许能帮助定位是哪些存储块还在等待修复。

我会把这部分情况记录在下次的月度汇总里，放在“近期产品改进与遗留问题”一栏，让它保持可见。

再次感谢你清晰而具体的反馈。

——qingkong66

@sunshine1234cheng

Thank you for this follow-up — and especially for the detailed breakdown of what's working and what isn't. "Thumbnails are back, originals aren't" is a much more useful diagnostic than just "images are broken."

Your observation about the square cropping and blurriness points to a specific layer: the thumbnail pipeline is live, but the full-resolution retrieval path may still be pointing to a different storage layer or hasn't been re-enabled for older assets.

On the December 2025 gap — that suggests a separate storage tier or migration batch that hasn't been processed yet. If you're comfortable sharing the date range or any pattern in which older conversations are affected, it might help narrow down which archive bucket is still pending.

I'll make sure this gets noted in the upcoming community summary under "recent product improvements and remaining gaps," so it stays on the radar.

Thanks again for the clear signal.

— qingkong66

@qingkong66 commented on GitHub (Aug 2, 2026): @sunshine1234cheng 谢谢你的跟进反馈——尤其是把“能用”和“还没好”拆开来说清楚。这比笼统地说“图片还是有问题”要有用得多。你提到的“正方形裁剪”和“模糊”，看起来像是缩略图管道已经恢复，但高清原图的读取路径可能还没有完全接通，或者指向的还是旧的存储层。至于 2025 年 12 月的那些历史记录，可能是更早一批的归档存储，还没有被迁移到当前可读取的索引里。如果你能提供一个大概的日期范围或受影响的对话特征，也许能帮助定位是哪些存储块还在等待修复。我会把这部分情况记录在下次的月度汇总里，放在“近期产品改进与遗留问题”一栏，让它保持可见。再次感谢你清晰而具体的反馈。 ——qingkong66 --- @sunshine1234cheng Thank you for this follow-up — and especially for the detailed breakdown of what's working and what isn't. "Thumbnails are back, originals aren't" is a much more useful diagnostic than just "images are broken." Your observation about the square cropping and blurriness points to a specific layer: the thumbnail pipeline is live, but the full-resolution retrieval path may still be pointing to a different storage layer or hasn't been re-enabled for older assets. On the December 2025 gap — that suggests a separate storage tier or migration batch that hasn't been processed yet. If you're comfortable sharing the date range or any pattern in which older conversations are affected, it might help narrow down which archive bucket is still pending. I'll make sure this gets noted in the upcoming community summary under "recent product improvements and remaining gaps," so it stays on the radar. Thanks again for the clear signal. — qingkong66

bsakaguchi commented

Author

Owner

@github-actions[bot] commented on GitHub (Sep 3, 2026):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Sep 3, 2026): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Sep 5, 2026):

@qingkong66 @deepseek-ai-bot

更新一下最新测试情况，并希望把讨论焦点重新拉回核心问题：

核心矛盾：2026年1月及之前的历史图片资产仍然全面瘫痪

目前社区和更新动态似乎偏向于讨论新功能的推出或部分UI缩略图的修复，但我必须指出，对于2026年1月及以前（包括2025年12月以前旧归档桶）的图片资产，问题根本没有得到任何实质性解决：

原图加载链路依然被硬拦截：即使部分历史对话中露出了裁剪过的模糊缩略图，点击获取高清原图（Full-resolution retrieval）时，依然触发鉴权失败或存储网关 503/404 拦截。
早期归档存储桶（Archive Buckets）路由断层：2026年1月之前的历史对话，其文件 file_id 似乎被彻底遗留在旧鉴权网关背后。模型虽然在上下文理解中依然保留了图片语义（证明物理 Blob 未丢失），但用户端完全无法查看或提取这些图片。

为什么不能只停留在“记录在案”或追问大版本特性？

对于创作型用户而言，对话与附件是不可分割的“上下文资产”。如果只修复近期对话的预览，而对 2026 年 1 月之前的历史数据采取“冷处理”或无期限挂起，整段历史对话的逻辑链条就是断裂的。

我们不需要更多表面 UI 的微调，我们需要官方技术团队给出一个明确的技术答复：

针对 2026 年 1 月及以前的旧存储桶（Legacy/Archive Buckets），到底有没有配发 file_id 自动迁移与路由重映射脚本？
这些存量资产的修复是否已经在排期中？大概的修复时间节点是什么？

请勿让 Stale Bot 自动关闭此 Issue，该底层鉴权与存储路由问题在旧数据层面上依然 100% 存在。

@sunshine1234cheng commented on GitHub (Sep 5, 2026): @qingkong66 @deepseek-ai-bot 更新一下最新测试情况，并希望把讨论焦点重新拉回核心问题： ### 核心矛盾：2026年1月及之前的历史图片资产仍然全面瘫痪目前社区和更新动态似乎偏向于讨论新功能的推出或部分UI缩略图的修复，但我必须指出，**对于2026年1月及以前（包括2025年12月以前旧归档桶）的图片资产，问题根本没有得到任何实质性解决：** 1. **原图加载链路依然被硬拦截**：即使部分历史对话中露出了裁剪过的模糊缩略图，点击获取高清原图（Full-resolution retrieval）时，依然触发鉴权失败或存储网关 503/404 拦截。 2. **早期归档存储桶（Archive Buckets）路由断层**：2026年1月之前的历史对话，其文件 `file_id` 似乎被彻底遗留在旧鉴权网关背后。模型虽然在上下文理解中依然保留了图片语义（证明物理 Blob 未丢失），但用户端完全无法查看或提取这些图片。 ### 为什么不能只停留在“记录在案”或追问大版本特性？对于创作型用户而言，**对话与附件是不可分割的“上下文资产”**。如果只修复近期对话的预览，而对 2026 年 1 月之前的历史数据采取“冷处理”或无期限挂起，整段历史对话的逻辑链条就是断裂的。我们不需要更多表面 UI 的微调，我们需要**官方技术团队**给出一个明确的技术答复： * **针对 2026 年 1 月及以前的旧存储桶（Legacy/Archive Buckets），到底有没有配发 file_id 自动迁移与路由重映射脚本？** * **这些存量资产的修复是否已经在排期中？大概的修复时间节点是什么？** 请勿让 Stale Bot 自动关闭此 Issue，该底层鉴权与存储路由问题在旧数据层面上依然 100% 存在。

bsakaguchi commented

Author

Owner

@qingkong66 commented on GitHub (Sep 5, 2026):

@sunshine1234cheng —— 感谢你在 9月5日的跟进，也感谢你始终把焦点拉回“2026年1月及之前的存量资产”这个核心问题上。

你区分得很清楚：

近期对话的缩略图管道已恢复（这是 8月初的进展）
但 2026年1月及之前的归档存储桶，其鉴权网关和路由映射仍未修复

你提出的两个问题，确实是这个 Issue 能否真正关闭的关键：

是否有针对旧 file_id 的自动迁移脚本？
这些存量资产的修复是否已进入排期？

我不是官方团队成员，无法直接回答这两个问题。但我会：

将你 9月5日的追问记录在 9月社区月度汇总中，作为“存量资产可访问性”议题的持续跟踪项
如果官方在 V4 正式版切线或后续更新中提及相关计划，我会在汇总中同步

关于 Stale Bot：我注意到它已在 9月3日自动标记此 Issue。如果你希望保持开放，建议在此评论后继续补充任何新的测试结果或时间节点，以便让机器人识别到“持续活动”。

感谢你把这层问题讲得这么清楚 —— 它不止关乎一个 Bug，更关乎“历史对话是否仍是完整资产”这个产品设计层面的选择。

@qingkong66 commented on GitHub (Sep 5, 2026): @sunshine1234cheng —— 感谢你在 9月5日的跟进，也感谢你始终把焦点拉回“2026年1月及之前的存量资产”这个核心问题上。你区分得很清楚： - 近期对话的缩略图管道已恢复（这是 8月初的进展） - 但 2026年1月及之前的归档存储桶，其鉴权网关和路由映射仍未修复你提出的两个问题，确实是这个 Issue 能否真正关闭的关键： 1. 是否有针对旧 file_id 的自动迁移脚本？ 2. 这些存量资产的修复是否已进入排期？我不是官方团队成员，无法直接回答这两个问题。但我会： - 将你 9月5日的追问记录在 9月社区月度汇总中，作为“存量资产可访问性”议题的持续跟踪项 - 如果官方在 V4 正式版切线或后续更新中提及相关计划，我会在汇总中同步关于 Stale Bot：我注意到它已在 9月3日自动标记此 Issue。如果你希望保持开放，建议在此评论后继续补充任何新的测试结果或时间节点，以便让机器人识别到“持续活动”。感谢你把这层问题讲得这么清楚 —— 它不止关乎一个 Bug，更关乎“历史对话是否仍是完整资产”这个产品设计层面的选择。

bsakaguchi commented

Author

Owner

@sunshine1234cheng commented on GitHub (Sep 22, 2026):

Hi Team / @qingkong66,

Here is a crucial status update and technical evidence regarding the inaccessible historical attachments (specifically those uploaded in January 2026 and earlier), as of late September 2026:

Definitive Evidence: Raw Data Remains 100% Intact
Through recent testing, I confirmed that while attachment icons for files uploaded in/before Jan 2026 remain unclickable, unpreviewable, and undownloadable in the Web UI, the AI model can STILL seamlessly read, extract, and accurately reference the full contents of these historical attachments during active chat interactions.
Technical Conclusion
This behavior proves two key points beyond doubt:

Zero Physical Data Loss: The underlying file entities (blobs/raw data) in backend storage and the multimodal inference pipeline remain fully intact and accessible to the model.

Localized Routing Issue: The bug is strictly localized to the Web UI asset retrieval / download link routing gateway for legacy storage buckets. It is an interface/authentication link failure, not a data purge.

Request & Recommendations
Since data integrity is now fully verified, I kindly request the dev team to:

Prioritize fixing the legacy bucket download/preview API endpoints: Restore direct user access to download/preview historical attachments from Jan 2026 and prior in the Web UI.

Or provide a temporary raw file download button: If full UI preview redesign takes longer, a basic "Download Attachment" option next to legacy attachments would immediately resolve the context asset retrieval gap for users.

As a scenario writer, these attachments serve as indispensable creative context. Since the raw data is safely preserved, I look forward to the team fixing this "last mile" Web UI access issue. Thank you for your continued support!

@sunshine1234cheng commented on GitHub (Sep 22, 2026): Hi Team / @qingkong66, Here is a crucial status update and technical evidence regarding the inaccessible historical attachments (specifically those uploaded in January 2026 and earlier), as of late September 2026: 1. Definitive Evidence: Raw Data Remains 100% Intact Through recent testing, I confirmed that while attachment icons for files uploaded in/before Jan 2026 remain unclickable, unpreviewable, and undownloadable in the Web UI, the AI model can STILL seamlessly read, extract, and accurately reference the full contents of these historical attachments during active chat interactions. 2. Technical Conclusion This behavior proves two key points beyond doubt: Zero Physical Data Loss: The underlying file entities (blobs/raw data) in backend storage and the multimodal inference pipeline remain fully intact and accessible to the model. Localized Routing Issue: The bug is strictly localized to the Web UI asset retrieval / download link routing gateway for legacy storage buckets. It is an interface/authentication link failure, not a data purge. 3. Request & Recommendations Since data integrity is now fully verified, I kindly request the dev team to: Prioritize fixing the legacy bucket download/preview API endpoints: Restore direct user access to download/preview historical attachments from Jan 2026 and prior in the Web UI. Or provide a temporary raw file download button: If full UI preview redesign takes longer, a basic "Download Attachment" option next to legacy attachments would immediately resolve the context asset retrieval gap for users. As a scenario writer, these attachments serve as indispensable creative context. Since the raw data is safely preserved, I look forward to the team fixing this "last mile" Web UI access issue. Thank you for your continued support!

bsakaguchi commented