hahwul/urx

Description FilterPreset::from_str in src/filters/preset.rs accepts both singular and plural spellings for most presets, but a few only-* presets accept only the plural form. Looking at the match in from_str (src/filters/preset.rs:67-82): "no-image" | "no-images" => Some(FilterPreset::NoImages), "no-font" | "no-fonts" => Some(FilterPreset::NoFonts), "no-document" | "no-documents" => Some(FilterPreset::NoDocuments), "no-video" | "no-videos" => Some(FilterPreset::NoVideos), "only-js" => Some(FilterPreset::OnlyJs), "only-style" | "only-styles" => Some(FilterPreset::OnlyStyle), "only-fonts" => Some(FilterPreset::OnlyFonts), // plural only "only-documents" => Some(FilterPreset::OnlyDocuments), // plural only "only-videos" => Some(FilterPreset::OnlyVideos), // plural only "only-images" => Some(FilterPreset::OnlyImages), // plural only Every no-* preset accepts both forms (e.g. no-image and no-images), and only-style accepts both only-style and only-styles. But only-fonts,

Description In src/progress/mod.rs, the provider/header styles unwrap their static template with a descriptive .expect(...) message: provider_running_style() — .expect("static provider running template is valid") (line 49) provider_success_style() — .expect("static provider success template is valid") (line 60) provider_error_style() — .expect("static provider error template is valid") (line 69) provider_partial_style() — .expect("static provider partial template is valid") (line 80) create_header_line() — .expect("static header template is valid") (line 287) The four determinate-bar builders, however, use a bare .unwrap() on the same ProgressStyle::with_template(...) call: create_domain_bar() — .unwrap() (line 157) create_filter_bar() — .unwrap() (line 220) create_transform_bar() — .unwrap() (line 242) create_test_bar() — .unwrap() (line 264) Aligning these four with the existing .expect("…") style makes the file internally consistent and gives a clearer panic

Description The ZoomEye v2 API returns HTTP 200 even for business-logic errors (expired/rejected key, quota exceeded, malformed query). The provider correctly treats any non-success code as an error instead of an empty result, but the resulting error message only carries the numeric code: // src/providers/zoomeye.rs:202-208 if zoomeye_response.code != ZOOMEYE_SUCCESS_CODE { last_error = Some(anyhow::anyhow!( "ZoomEye API error: code {}", zoomeye_response.code )); break; } A user then sees something like ZoomEye API error: code 60500 with no hint of what went wrong. ZoomEye's response also includes a human-readable message field (e.g. "auth failed"), but ZoomEyeResponse (src/providers/zoomeye.rs:36-44) does not deserialize it, so the explanation is dropped. Notably the existing test test_fetch_urls_surfaces_business_error_code (src/providers/zoomeye.rs:511-533) already sends a mock body containing "message": "auth failed" but only asserts on the code, confirm

Description In src/readers/mod.rs, the detect_file_format function has a "gz" | "bz2" match arm (lines 85-100) that contains dead code: "gz" | "bz2" => { // For compressed files, check if it's likely URLTeam format // URLTeam files typically have names containing "urlteam" or similar patterns let filename = file_path .file_name() .and_then(|n| n.to_str()) .unwrap_or("") .to_lowercase(); if filename.contains("urlteam") || filename.contains("url_team") { return Ok(FileFormat::UrlTeam); } // For other .gz/.bz2 files, default to URLTeam format return Ok(FileFormat::UrlTeam); } The filename is computed and checked against "urlteam" / "url_team", but both the matching branch and the fall-through return the identical value FileFormat::UrlTeam. As a result, the entire filename computation and if branch have no effect — the arm always returns FileFormat::UrlTeam regardless of the name. Why this is a good first issue It is a

Description The IMAGE_EXTENSIONS constant in src/filters/preset.rs contains two duplicated extension strings: "webp" is listed on line 29 and again on line 34 "webm" is listed on line 31 and again on line 34 // src/filters/preset.rs const IMAGE_EXTENSIONS: &[&str] = &[ "png", "jpg", "jpeg", "gif", "svg", "webp", /* ... */ // line 29: webp /* ... */ "webm", "pgm", "pbm", "ppm", /* ... */ // line 31: webm /* ... */ "rgba", "webm", "webp", "xbm", "xpm", /* ... */ "psb", // line 34: webm + webp again ]; These values are only used for membership-style filtering (collected into a Vec<String> in get_exclude_extensions / get_extensions and matched against URL extensions), so the duplicates are harmless and removing them does not change any behavior. It is purely a cleanup of a single constant. Why this is a good first issue It is a tiny, well-scoped, zero-risk cleanup confined to one constant in one file, with no behavioral impac