Make BulkInfoProviderService GREAT again.

[RawSmokeTerribilus]

Added logic to clean provider keys and handle corrupted keys during bulk processing.

Don´t hate me, vibe coded it. it works on my machine lol. Nah joking, it has been vibe coded but it does work perfectly fine in my container, i run the latest image. The feature is amazing! we were needing it working.

I have ONLY modified the file: src/Services/InfoProviderSystem/BulkInfoProviderService.php

Love you guys, amazing work!!!

[RawSmokeTerribilus]

Technical Review & Action Plan for Bulk Info Provider Fix

Subject: Fixing Invalid provider key type error in BulkInfoProviderService

1. Initial Problem Analysis

The primary reported symptom was that all bulk info provider jobs were failing immediately with a RuntimeException: No search results found for any of the selected parts.

Initial log analysis revealed that the root cause was not a lack of results, but a fatal error occurring before any API calls were made. The fieldMappings->providers array, which should contain simple string keys like "lcsc", was found to contain a corrupted data structure.

When a provider class (e.g., App\Services\InfoProviderSystem\Providers\LCSCProvider) was cast to an array, it included its private properties, resulting in a complex key structure contaminated with null bytes:

Corrupted Key Example:
\0App\Services\InfoProviderSystem\Providers\LCSCProvider\0lcscClient

The core logic was failing to match the expected clean key (e.g., "lcsc") against this corrupted key during in_array() checks, causing all providers to be silently skipped and leading to the "No search results" error.

The current working patch (the one submitted in this PR) implements a robust, multi-step cleaning and matching logic to handle this specific data corruption:

• Key Cleaning: New logic was added to performBulkSearch to iterate over provider keys. If a key is not a string, it's assumed to be the corrupted object/array.

• Null Byte Removal: The key is processed with str_replace("\0", '', ...) to remove the null bytes introduced by the private property casting.

• Greedy Regex Matching: The cleaned string (e.g., App\...LCSCProviderlcscClient) is processed with a greedy regex preg_match('/.*\\\\([\w]+Provider)/', ...) to extract the last valid class name (e.g., LCSCProvider), correctly ignoring InfoProvider from the namespace.

• Helper Function: A private helper method, providerKeyMatches(string $cleanedKey, array $providerList), was created. This function centralizes the new cleaning logic, allowing a clean key (like "lcsc") to be correctly matched against a list still containing the corrupted key.

• Patching Call-sites: All instances where in_array() or array_intersect() were used to check for a provider key (in processBatchProviders, processRegularProviders, and collectKeywordsForProvider) were replaced with calls to the new providerKeyMatches() helper.

Status: This patch successfully resolves the primary bug. The main bulk import workflow (Step 1) now correctly parses the provider keys, collects the part keywords, and successfully fetches results from the provider API.

3. Current Status & New Finding (The "Research All" Bug)

While Patch 11.1 fixes the main workflow, further testing revealed a minor edge case. When a job is already in Step 2 (review), clicking the "Research All" button (/job/{id}/research-all) fails.

Log analysis of this specific action shows that the performBulkSearch function is being called with a fieldMapping that contains an empty array ([]) as one of the providers.

The cleaning logic in Patch 11.1 was not designed to handle an empty array (it expects an object or a string). This causes it to log an Invalid provider key type AFTER cleanup {"providerKey":[],"type":"array"} error and fail the "Research All" process.

4. Action Plan (Final Fix)

The fix for this final edge case is minor and builds directly upon the working code in this Pull Request.

• Objective: Make the key cleaning logic in performBulkSearch robust enough to handle these "empty array" providers silently.

• The Fix: A single check will be added to the performBulkSearch loop. Before attempting to clean a non-string key, it will first check if it's an empty array.

Conceptual Code (to be added to performBulkSearch):

// Inside the main provider loop...
if (!is_string($providerKey)) {
    
    // [NEW FIX]
    // Silently skip if the provider mapping is just an empty array
    if (is_array($providerKey) && empty($providerKey)) {
        $this->logger->info('Skipping empty array provider key from mapping.');
        continue; 
    }
    // [END NEW FIX]

    // ... existing cleaning logic for corrupted objects ...
}

(Note: A previous attempt to implement this fix (Patch 11.2) contained a fatal syntax error ($this.logger vs $this->logger) which caused a 500 error. This was an authoring mistake and has been identified.)

Conclusion: This Pull Request (Patch 11.1) solves 99% of the critical bug. The final research-all issue is understood and a minor, safe addition (as shown above) will resolve it completely.