Skip to content

fix(core.api.client): aggregate fetch_all_mods errors - #55

Open
BinToss wants to merge 2 commits into
Tekunogosu:omegafrom
BinToss:bintoss/fix/aggregate-sync-errors
Open

fix(core.api.client): aggregate fetch_all_mods errors#55
BinToss wants to merge 2 commits into
Tekunogosu:omegafrom
BinToss:bintoss/fix/aggregate-sync-errors

Conversation

@BinToss

@BinToss BinToss commented Apr 18, 2026

Copy link
Copy Markdown
Contributor

Because this solution wraps a Result with another Result, it increases complexity a bit. But this is more acceptable than alternatives such as...

  • Change the return type of ApiClient.fetch_mod to accommodate a String-type alternative result. fetch_mod would never use this alternative return type; only callers would use it. This breaking change had insufficient justification.
  • Store error messages in a Mutex<Vec<String>>. Each task would use i to index into their own, exclusive entries in the vector. However, the compiler was not satisfied by the way I wanted to do it. I could have added a thread-safe Vector dependency or implemented a message queue, but both were big changes for what seemed like a small problem.

Fixes #54 "Errors in fetch_all_mods interrupt the progress bar"


Example Output:

> rustique sync
╭─────────────────────────────────────────────────────────────────────────╮
  Syncing...   /home/noah/Games/VintageStory/VSInstallations/latest/Mods/
╰─────────────────────────────────────────────────────────────────────────╯
  [00:00:04] [████████████████████] 396/396 Fetch Complete                                                          2026-04-18T01:09:35.612905Z ERROR main ThreadId(01) err="Failed: \u{1b}[31mentityemotelib\u{1b}[39m\nError:\n\u{1b}[31mmissing field `mod` at line 1 column 20\u{1b}[39m\n"
2026-04-18T01:09:35.612921Z ERROR main ThreadId(01) err="Failed: \u{1b}[31mentitycolortint\u{1b}[39m\nError:\n\u{1b}[31mmissing field `mod` at line 1 column 20\u{1b}[39m\n"
╭────────────────────────────────────╮
  Sync operation completed:    5.26s
╰────────────────────────────────────╯

@BinToss

BinToss commented Apr 18, 2026

Copy link
Copy Markdown
Contributor Author

Should I try stripping out the control and color characters?

@Tekunogosu

Copy link
Copy Markdown
Owner

The control and color characters are not from the mods themselves, but rustique. It should actually show colors and work in a normal terminal, at least on linux it should.

Your solution to this issue looks good enough I think for now, but it'll be a little bit before I have the time to merge/test it. I really appreciate your contributions to rustique!

@Tekunogosu

Copy link
Copy Markdown
Owner

I'm doing some work on rustique again and looking into this. What terminal are you using and what mod is this error from?

@BinToss

BinToss commented Apr 22, 2026

Copy link
Copy Markdown
Contributor Author

I usually use Fish in Konsole.
I think those characters are also escaped when running Fish in Vs code's xterm.js-based terminal. I'll check that and Bash and Powershlell 7 in Konsole, later today.

@Tekunogosu

Copy link
Copy Markdown
Owner

Gotcha, thanks. I think I found the issue because yea, its not working for me either with zsh in yakuake. It looks like the info!/debug,warn macros are escaping the color control characters, at least thats what it seems.

@Tekunogosu

Copy link
Copy Markdown
Owner

So the issue was the tracing library sanitizes ansi characters by default. There is an option to disable that sanitation when creating the rules for logging which seems to make it work.

Because this solution wraps a Result with another Result, it increases complexity a bit, but this is more acceptable than alternatives such as...
- Change the return type of `ApiClient.fetch_mod` to accommodate a String-type alternative result. `fetch_mod` would never use this alternative return type; only callers would use it. This breaking change had insufficient justification.
- Store error messages in a `Mutex<Vec<String>>`. Each task would use `i` to index into their own, exclusive entries in the vector. However, the compiler was not satisfied by the way I wanted to do it. I could have added a thread-safe Vector dependency or implemented a message queue, but both were big changes for what seemed like a small problem.

Fixes Tekunogosu#54 "Errors in `fetch_all_mods` interrupt the progress bar"
@BinToss
BinToss force-pushed the bintoss/fix/aggregate-sync-errors branch from 783e77f to 4292bbe Compare April 29, 2026 23:30
@BinToss

BinToss commented Apr 30, 2026

Copy link
Copy Markdown
Contributor Author

The color codes here still aren't escaped after rebasing onto v0.5.16

Oh, well. It's not in the scope of the merge request, anyway.

@Tekunogosu

Copy link
Copy Markdown
Owner

Hmm that's weird. It all works for me, well I don't see the color codes anyway. I noticed it's also showing the err="" part too. Are you doing something to show more debug info? Because that might be doing it.

Screenshot_20260429_220928

@BinToss

BinToss commented May 2, 2026

Copy link
Copy Markdown
Contributor Author

I noticed it's also showing the err="" part too.

Ah.
I seem to be serializing an Err Result.


The strings passed into the error!(err) are fine. So, the error! macro's error!(&String) match (arm \#47) was formatting the string differently than expected. Refactoring the call to error!("{}", &String) (arm 48) outputs as expected:

This fixes the unexpectedly re-formatted error messages issue introduced in 4292bbe
@BinToss

BinToss commented May 14, 2026

Copy link
Copy Markdown
Contributor Author

I see why you haven't included this in branch v0.6.0. The combination makes the output even noisier than it used to be.
https://asciinema.org/a/12jOGlKrUZQAfSRJ/
rustique_sync.stdout.gist

@Tekunogosu

Copy link
Copy Markdown
Owner

oh wow, yea thats super noisy. Honestly, I just hadn't gotten around to merging it and testing it out yet, but after seeing this, maybe not XD. I'll have to figure out a good solution.

@Tekunogosu

Copy link
Copy Markdown
Owner

Though, actually from looking at that posted log, its only noisy because the pinned condition is too strict for the mods, or the mods just don't have an updated version for what you have pinned anyway. So might not be what you merged with the code.

@BinToss

BinToss commented May 14, 2026

Copy link
Copy Markdown
Contributor Author

Ah. Yeah. I'll post the pinned mod list later.

@Tekunogosu

Copy link
Copy Markdown
Owner

With 0.6.0 you can set better conditions and even ranges for pinning versions.

Things like: ">=1.22.*" or ">1.22.0, <=1.22.5" things like that. But if you get too strict then nothing matches and you get a lot of output. I need to make an aggregate list I think so it tells you everything at once, because that output spam is a lot when you have a ton of mods.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Errors in fetch_all_mods interrupt the progress bar

2 participants