fix(core.api.client): aggregate fetch_all_mods errors - #55
Conversation
|
Should I try stripping out the control and color characters? |
|
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! |
|
I'm doing some work on rustique again and looking into this. What terminal are you using and what mod is this error from? |
|
I usually use Fish in Konsole. |
|
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. |
|
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"
783e77f to
4292bbe
Compare
Ah. The strings passed into the |
This fixes the unexpectedly re-formatted error messages issue introduced in 4292bbe
|
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. |
|
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. |
|
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. |
|
Ah. Yeah. I'll post the pinned mod list later. |
|
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. |







Because this solution wraps a
Resultwith anotherResult, it increases complexity a bit. But this is more acceptable than alternatives such as...ApiClient.fetch_modto accommodate a String-type alternative result.fetch_modwould never use this alternative return type; only callers would use it. This breaking change had insufficient justification.Mutex<Vec<String>>. Each task would useito 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_modsinterrupt the progress bar"Example Output: