Fix download manager crash and dropped downloads - #2406
Open
TwistedModding wants to merge 3 commits into
Open
Conversation
DownloadList::data() called the throwing getPendingDownload() for a pending row that could have transitioned to an active download between the model reporting its row count and the view querying the row, aborting with "get pending: invalid download index". Add a non-throwing tryGetPendingDownload() and use it so a stale row returns an empty value. nxm links forwarded by short-lived secondary processes were dropped when the UI thread was busy (resolving a Nexus URL, or rescanning a large downloads folder), producing "failed to receive data from secondary process" for downloads started in quick succession. Move the local socket server onto a dedicated thread so connections are read the instant they arrive regardless of UI-thread load, keep the sender connected until the primary has read the message, and debounce the downloads-folder rescan so a burst of file changes no longer freezes the event loop.
Contributor
|
Looks good to my eyes. I'll take it for a test ride if I can get my setup running again, as I have had this issue from IO stalls regularly |
schlosserleo
added a commit
to mo2-modern/modorganizer
that referenced
this pull request
Aug 15, 2026
…dropped downloads) ModOrganizer2#2406 by TwistedModding, +135/-53 across 6 files in the download manager and the single-instance IPC: downloadlist, downloadmanager, multiprocess.⚠️ Weaker upstream evidence than ModOrganizer2#2417. It is unmerged and unreviewed (opened 2026-06-12, REVIEW_REQUIRED), and where ModOrganizer2#2417 at least had upstream build and lint checks pass, this one has only pre-commit.ci -- upstream CI has never compiled it. Our /W4 /WX build is now the only compiler that has. version.rc is deliberately resolved to OURS, discarding their third commit entirely. It bumps the version to 2.5.3beta12 and sets FILEFLAGS to VS_FF_PRERELEASE, neither of which has anything to do with fixing downloads -- it is the author's own release prep riding along in a bugfix PR. Taking it would have renamed our build mid-merge and flipped createVersionInfo() onto the string-parsing branch, which is exactly the path ADR-028 chose the numeric side of. We stay at 2.5.2.1 with FILEFLAGS 0. That upstream is cutting 2.5.3 betas is worth noting separately: when they ship it, ADR-028 says we rebase onto 2.5.3 and become 2.5.3.1. modern also touches downloadmanager.cpp/.h, so the auto-merge was checked rather than trusted: all nine member-init sites survive, as does the TU-local `using namespace boost::accumulators` that keeps its extractors out of every includer.
schlosserleo
added a commit
to mo2-modern/modorganizer
that referenced
this pull request
Aug 15, 2026
SimplisticMind (ModOrganizer2#2417, perf) and TwistedModding (ModOrganizer2#2406, download manager fixes) both wrote code this fork now ships, so both go in the About dialog's "MO2 Developers & Contributors" list. Two judgement calls worth stating rather than burying. SimplisticMind was already in the dialog, under "Other Supporters & Contributors". That entry is upstream's and is left exactly as it is -- editing it would be editorialising on upstream's own structure for no gain -- so the name now appears twice, in two lists that mean different things. That is mildly odd to look at and more accurate than either alternative. TwistedModding is the GitHub handle; the git author on those commits reads "Teddy Lybold". The handle is used because it matches how the PR is attributed and how the surrounding entries are written, several of which are handles. Easy to change if they would rather be credited by name. Neither replaces the credit that already exists in git: both PRs were merged rather than cherry-picked, so their commits keep their original authorship and SHAs.
schlosserleo
added a commit
to mo2-modern/modorganizer
that referenced
this pull request
Aug 15, 2026
Second fork release. Carries upstream PRs ModOrganizer2#2417 (perf) and ModOrganizer2#2406 (download manager and single-instance IPC fixes), both merged and both confirmed working by the owner: the mod list under ModOrganizer2#2417's file-tree changes, and the download and second-instance paths under ModOrganizer2#2406's. Fourth segment only, per ADR-028. Upstream still owns 2.5.3, and is currently cutting betas of it -- when they ship, this rebases onto 2.5.3 and becomes 2.5.3.1. Fork identity; do not include in any PR branch cut from master.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DownloadList::data() called the throwing getPendingDownload() for a pending row that could have transitioned to an active download between the model reporting its row count and the view querying the row, aborting with "get pending: invalid download index". Add a non-throwing tryGetPendingDownload() and use it so a stale row returns an empty value.
nxm links forwarded by short-lived secondary processes were dropped when the UI thread was busy (resolving a Nexus URL, or rescanning a large downloads folder), producing "failed to receive data from secondary process" for downloads started in quick succession. Move the local socket server onto a dedicated thread so connections are read the instant they arrive regardless of UI-thread load, keep the sender connected until the primary has read the message, and debounce the downloads-folder rescan so a burst of file changes no longer freezes the event loop.