[Bug]: Doubao export is non-deterministic on virtual-scroll conversations in Ophel Atlas 1.1.5

[AstraVanX]

Essential Checklist

• I have searched for existing issues and confirmed this is not a duplicate
• I understand that the issue may be closed if missing reproduction steps or environment info
• I have starred the project 🌟
• I am willing to contribute a Pull Request for this

Installation Type

Browser Extension

Userscript Manager

None

Ophel Version

1.1.5

AI Platform

Doubao (www.doubao.com)

Browser

Chrome

Browser Version

No response

Operating System

Windows

Bug Description

Repeated exports of two unchanged Doubao conversations are not deterministic.

• Short sample: both runs contained 19 messages (9 user / 10 assistant) and the same role+content multiset, but the final two records swapped (LCS 18; file SHA-256 differed).
• Long virtual-scroll sample: 343 vs 425 messages (169/174 vs 212/213 user/assistant); role+content multiset intersection 298, run-1-only 45, run-2-only 127, LCS 288. First/last records, role counts, image references, and file SHA-256 all differed. Duplicate role+content records were 2 vs 3.
• No manual scrolling; each run refreshed the same conversation and exported independently.
• Message objects contained only role and content: no stable message ID, timestamp, parent, branch, or regenerate field.
• JSON retained external references but created no local asset bundle. Long-run image references differed (5 vs 9).
• A Markdown export stayed at Preparing export for at least 296.22 seconds and produced no file.

Privacy: no raw export, title, conversation ID/URL, account data, or message text is attached. Aggregate statistics were recomputed locally.

Steps to Reproduce

1. Open a Doubao conversation.
2. Export it as JSON with Ophel Atlas.
3. Refresh the same conversation.
4. Export again with identical settings.
5. Compare role, content hashes, message order, and asset references.

Expected vs Actual Behavior

Expected: Repeated exports of an unchanged conversation produce the same complete, normalized first-to-last sequence; no random omissions, reordering, or duplicates; promised assets are traceable offline; failures show an explicit error.

Actual: The short sample swaps its final two records. The long sample changes from 343 to 425 messages with only a partial stable intersection, and asset references drift. A Markdown export can remain at Preparing export for at least 296 seconds without producing a file.

Screenshots

No response

Console Errors

[github-actions]

👋 Thanks for opening an issue!

We will look into it soon. If Ophel is helpful to you, please consider giving the repo a Star 🌟. It means a lot!

[urzeye]

Thanks for the detailed report and the aggregate comparison. I currently do not have a Doubao conversation long enough to reproduce the 343/425-message virtual-scroll behavior. Would you be willing to share a Doubao conversation link that reproduces the issue? A read-only shared conversation with any sensitive content removed would be sufficient. If you prefer not to post it publicly, you can send it to me privately.

A few additional notes from my initial review:

• The different message counts, order, duplicates, and image-reference sets strongly suggest that the virtual-scroll collection is not reaching a stable and complete result. The current implementation scans the conversation at predetermined scroll positions and waits a fixed 120 ms after each scroll, which may be insufficient when Doubao is still mounting rows, recalculating heights, or loading content.
• The final-two-message swap may be a separate ordering issue. Messages can receive the same or unstable virtual position, and the current merge step does not have a sufficiently strong secondary ordering key.
• The Markdown export remaining at “Preparing export...” is also a valid issue. The scan currently has no explicit timeout or convergence check, and export failures are primarily logged to the console rather than shown as a clear user-facing error.
• One caveat regarding the full-file SHA-256 comparison: exported files contain an exportTime field, so two otherwise identical exports can still have different file hashes. The differing message sequences, counts, duplicates, and asset references are the stronger evidence here.
• JSON export currently preserves external asset references but does not create a local asset bundle. Local asset packaging is currently limited to Markdown + ZIP, so JSON asset bundling would be a separate enhancement. However, the reference set for the same unchanged conversation should still remain consistent.
• Exported message objects currently contain only role and content. Adding stable IDs or attachment metadata may improve traceability, but the immediate bug is that repeated exports should first produce the same complete and correctly ordered message sequence.

With a reproducible shared conversation, I can inspect how Doubao’s virtual list behaves at that scale and determine a reliable completion and ordering strategy.